From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Odd warning from pg_dump |
Date: | 2016-03-08 16:31:21 |
Message-ID: | 20160308163121.GP3127@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua D. Drake | 2016-03-08 16:38:04 | Re: Exclude pg_largeobject form pg_dump |
Previous Message | Jeff Janes | 2016-03-08 16:23:54 | Re: Freeze avoidance of very large table. |