On 01/31/2012 03:02 PM, Martijn van Oosterhout wrote:
On Mon, Jan 30, 2012 at 11:18:31PM -0500, Tom Lane wrote:
I don't recall that we thought very hard about what should happen when
pg_dump switches are used to produce a selective dump, but ISTM
reasonable that if it's "user data" then it should be dumped only if
data in a regular user table would be. So I agree it's pretty broken
that "pg_dump -t foo" will dump data belonging to a config table not
selected by the -t switch. I think this should be changed in both HEAD
and 9.1 (note that HEAD will presumably return to the 9.1 behavior once
that --exclude-table-data patch gets fixed).
Perhaps a better way of dealing with this is providing a way of dumping
extensions explicitly. Then you could say:
pg_dump --extension=postgis -s
to get the data. And you can use all the normal pg_dump options for
controlling the output. The flag currently used to seperate the table
schema from the table content could then interact logically. Another
way perhaps:
pg_dump --extension-postgis=data-only
pg_dump --extension-postgis=schema
pg_dump --extension-postgis=all
pg_dump --extension-postgis=none
This one won't fly. We use option processing that requires that the
option names to be known at compile time, so you can't embed an
arbitrary extension name in there.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
