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

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> =3D?UTF-8?Q?Mart=3Dc3=3Dadn_Marqu=3Dc3=3Da9s?=3D <martin@2ndquadrant.com>=
 writes:
> > This is a new version of your patch that checks for schema inclusion or
> > exclusion.
>=20
> > If there are no complains, I could apply similar changes on other
> > objects for a more complete patch.
>=20
> > Thoughts, objections?
>=20
> This patch seems to me to be entirely the wrong approach, as what it
> will result in is an enormous amount of code duplication.  There's
> nothing fundamentally wrong with looking at the parent namespace to
> decide whether to dump or not.  The difficulty is that we need to draw
> a distinction *at the namespace level* between "dump this namespace"
> and "dump objects within this namespace".  The correct behavior for
> a namespace owned by an extension is to do the latter (for objects
> not belonging to any extension) but not the former.  So instead of
> just one "dump" flag, we need two such flags for namespaces.  The
> various selectDumpableFoo routines need one-line adjustments as to
> which flag they look at in the parent namespace.  They do *not*
> need copy-and-paste of their entire current contents.

Agreed.

> 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.

> The DUMP_COMPONENT infrastructure doesn't exist in older branches
> so I think you'd just have to invent an additional bool field in
> NamespaceInfo structs to say whether to dump contained objects.

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.

If all we need is a flag for the back branches (I've not looked very
closely yet...), then I'd suggest simply adding that 'dump_contains'
field as a boolean in the back branches and using that.

> A slightly different approach is to ignore the DumpComponents stuff
> and just add a bool field in NamespaceInfo for all branches.  Perhaps
> this would even be the right thing, as I may be misunderstanding what
> Stephen intends the DumpComponents bits to be used for.  Would be
> interesting to hear Stephen's take on this.

Putting 'dump_contains' into the NamespaceInfo wouldn't work as objects
which are members of extensions are also "contained" by that extension,
allowing us to say things like "dump all of the ACLs for all of the
objects which are members of this extension, but not the extension
itself."

We could possibly rework it such that all 'dump_contains' bitmasks are
part of the data structures for the 'containing' object instead of being
associated with *every* object.  That might be a bit cleaner, but might
also mean that it gets forgotten as it's not sitting right next to the
main 'dump' bitmask.

Thanks!

Stephen