On Tue, Jul 10, 2012 at 2:43 PM, Bruce Momjian wrote:
> On Tue, Jul 10, 2012 at 01:03:18PM -0700, Maciek Sakrejda wrote:
>> So, is there hope of a better fix here for 9.2 (specifically for
>> preserving extension ownership on pg_upgrade and dump/restore, though
>> I understand it may not make sens
On Tue, Jul 10, 2012 at 01:03:18PM -0700, Maciek Sakrejda wrote:
> So, is there hope of a better fix here for 9.2 (specifically for
> preserving extension ownership on pg_upgrade and dump/restore, though
> I understand it may not make sense to do that if we can't fix a number
> of related issues)?
So, is there hope of a better fix here for 9.2 (specifically for
preserving extension ownership on pg_upgrade and dump/restore, though
I understand it may not make sense to do that if we can't fix a number
of related issues)? If not, is the below catalog-twiddling sane,
lacking an ALTER EXTENSION f
On Fri, Jul 06, 2012 at 08:38:01PM -0700, Maciek Sakrejda wrote:
> >> Well, the part I understood was that your fix apparently does not
> >> guarantee to restore plpgsql to the state it was in, just to restore
> >> it to existence. But previous complaints about similar issues have
> >> fallen on d
>> Well, the part I understood was that your fix apparently does not
>> guarantee to restore plpgsql to the state it was in, just to restore
>> it to existence. But previous complaints about similar issues have
>> fallen on deaf ears (see bug #5184). Perhaps Tom has had a change of
>> heart, but
On Fri, Jul 06, 2012 at 07:32:10PM -0400, Robert Haas wrote:
> On Thu, Jul 5, 2012 at 9:32 AM, Bruce Momjian wrote:
> > On Thu, Jul 05, 2012 at 12:21:58AM -0400, Tom Lane wrote:
> >> Bruce Momjian writes:
> >> >>> address the points I made about reproducing the previous state in cases
> >> >>> wh
On Thu, Jul 5, 2012 at 9:32 AM, Bruce Momjian wrote:
> On Thu, Jul 05, 2012 at 12:21:58AM -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>> >>> address the points I made about reproducing the previous state in cases
>> >>> where the admin removed the language or changed its permissions.
>>
>> >>
On Thu, Jul 05, 2012 at 12:21:58AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> >>> address the points I made about reproducing the previous state in cases
> >>> where the admin removed the language or changed its permissions.
>
> >> Well, it still does the create extension in binary mode lik
Bruce Momjian writes:
>>> address the points I made about reproducing the previous state in cases
>>> where the admin removed the language or changed its permissions.
>> Well, it still does the create extension in binary mode like before ---
>> not sure what the problem is.
> Applied and back-pa
On Mon, Jul 02, 2012 at 01:28:36PM -0400, Bruce Momjian wrote:
> This is the trimmed-down code block:
>
> if (!binary_upgrade)
> {
> appendPQExpBuffer(q, "CREATE EXTENSION IF NOT EXISTS %s WITH SCHEMA
> %s;\n",
> qextname, fmtId(extinfo->namespace));
>
On Mon, Jul 02, 2012 at 01:01:51PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > +
> > + /*
> > +* We unconditionally create the extension, so we must
> > drop it if it
> > +* exists. This could happen if the user deleted
> > 'plpgsql' and then
Bruce Momjian writes:
> +
> + /*
> + * We unconditionally create the extension, so we must
> drop it if it
> + * exists. This could happen if the user deleted
> 'plpgsql' and then
> + * readded it, causing its oid to be greater
On Sat, Jun 30, 2012 at 02:37:47PM -0400, Tom Lane wrote:
> > However, surprisingly, a simple pg_dump/restore also does not preserve
> > the public schema permissions either. :-(
>
> Right. My point is that there is a whole lot of stuff that initdb
> creates but does not mark "pinned" in pg_depe
Bruce Momjian writes:
> On Sat, Jun 30, 2012 at 11:12:56AM -0400, Tom Lane wrote:
>> Did it restore the nonstandard ownership of the schema?
> No --- drop/create of the public schema produces:
> ...
> However, surprisingly, a simple pg_dump/restore also does not preserve
> the public schema permi
On Sat, Jun 30, 2012 at 11:12:56AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Fri, Jun 29, 2012 at 11:35:15PM -0400, Tom Lane wrote:
> >> I think you're misjudging the core of the issue. The same thing
> >> would happen if somebody dropped and recreated the public schema.
> >> Or anyth
Bruce Momjian writes:
> On Fri, Jun 29, 2012 at 11:35:15PM -0400, Tom Lane wrote:
>> I think you're misjudging the core of the issue. The same thing
>> would happen if somebody dropped and recreated the public schema.
>> Or anything else that we create at initdb time but allow to be
>> dropped.
On Sat, Jun 30, 2012 at 01:00:07AM -0400, Bruce Momjian wrote:
> On Fri, Jun 29, 2012 at 11:35:15PM -0400, Tom Lane wrote:
> > Bruce Momjian writes:
> > > I can't think of how to fix this. Perhaps we need to query the
> > > pg_extension table as of the SELECT function all.
> >
> > I think you're
On Fri, Jun 29, 2012 at 11:35:15PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > I can't think of how to fix this. Perhaps we need to query the
> > pg_extension table as of the SELECT function all.
>
> I think you're misjudging the core of the issue. The same thing
> would happen if somebo
Bruce Momjian writes:
> I can't think of how to fix this. Perhaps we need to query the
> pg_extension table as of the SELECT function all.
I think you're misjudging the core of the issue. The same thing
would happen if somebody dropped and recreated the public schema.
Or anything else that we c
On Mon, Jun 25, 2012 at 10:57:56PM +, m.sakre...@gmail.com wrote:
> The following bug has been logged on the website:
>
> Bug reference: 6706
> Logged by: Maciek Sakrejda
> Email address: m.sakre...@gmail.com
> PostgreSQL version: Unsupported/Unknown
> Operating system: Ub
20 matches
Mail list logo
