Re: pg_dump doesn't dump new objects created in schemas from extensions - Mailing list pgsql-bugs

From Tom Lane
Subject Re: pg_dump doesn't dump new objects created in schemas from extensions
Date
Msg-id 30842.1466608326@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump doesn't dump new objects created in schemas from extensions  (Stephen Frost <sfrost@snowman.net>)
Responses Re: pg_dump doesn't dump new objects created in schemas from extensions  (Martín Marqués <martin@2ndquadrant.com>)
List pgsql-bugs
Stephen Frost <sfrost@snowman.net> writes:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>> In HEAD, this should be a pretty straightforward change since Stephen
>> Frost has already created infrastructure that allows distinguishing which
>> "components" of an object to dump.  There doesn't seem to be a bit that
>> corresponds to "objects within this schema", but that shouldn't be hard
>> to add.

> In HEAD, this already exists in the form of 'dump_contains', which sits
> next to 'dump' in the DumpableObject struct.  I added that independent
> field as it allows us to say things like "dump components X, Y, Z of
> this object, and components A, B, C of objects *contained* by this
> object."  What that means is that we can dump, say, just the privileges
> of a namespace, but dump all of the components of objects which live
> inside of that namespace.

Ah.  So maybe we just need to rearrange selectDumpableNamespace.
Offhand, it seems like we want checkExtensionMembership to adjust the
namespace's dump bits, but not its dump_contained bits (which indeed it
already doesn't, which until just now I would have said is an oversight).
So maybe just moving the checkExtensionMembership call to after the other
stuff would be enough in HEAD?

            regards, tom lane

pgsql-bugs by date:

Previous
From: Konstantin Belousov
Date:
Subject: Re: BUG #14206: Switch to using POSIX semaphores on FreeBSD
Next
From: Tom Lane
Date:
Subject: Re: BUG #14206: Switch to using POSIX semaphores on FreeBSD