Re: Odd warning from pg_dump - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Odd warning from pg_dump
Date
Msg-id 20160308163121.GP3127@tamriel.snowman.net
Whole thread Raw
In response to Re: Odd warning from pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I think the real question is if "-n '*'" should still exclude
> > 'pg_catalog'.  Fixing the issue with defined pseudo types is wonderful,
> > but aren't you going to end up with a dump you can't restore,
> > regardless?
>
> Yeah, perhaps so.  The thread on -general has also produced the
> information that pg_dump -t '*' tries to dump system catalogs as if
> they were user tables, which is another pretty useless bit of behavior.

Indeed.

> So maybe we should drop the hunk you've got there (which frankly seems a
> bit of a kluge) and instead hot-wire things so that stuff in pg_catalog
> is excluded even if it would otherwise match the inclusion lists.

An idealistic viewpoint might be that we should provide a way to
actually create defined pseudo-types and then make pg_dump work with
them, but I have a hard time seeing why that would be worth the effort.
One might also argue that we should have a way of dealing with every
type of object which exists and defined psuedo-types seem to be the only
thing left out.

I agree that it seems like the best idea is to just hot-wire pg_dump to
exclude pg_catalog, though I'm inclined to suggest that we just exclude
it from pattern matches.  We know that objects sometimes end up in
pg_catalog which aren't really supposed to be there and there might be
other reasons to want to dump it out, so having 'pg_dump -n pg_catalog'
still do its best to dump out what's been asked for seems reasonable.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Fabien COELHO
Date:
Subject: Re: extend pgbench expressions with functions