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
The last being the default.
Just throwing out some completely different ideas.
Have a nice day,
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
-- Arthur Schopenhauer
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2012-01-31 20:15:42|
|Subject: Re: JSON for PG 9.2|
|Previous:||From: Robert Haas||Date: 2012-01-31 19:49:52|
|Subject: Re: Index-only scan performance regression|
pgsql-general by date
|Next:||From: Scot Kreienkamp||Date: 2012-01-31 20:19:15|
|Subject: Re: list blocking queries |
|Previous:||From: Nykolyn, Andy (AS)||Date: 2012-01-31 19:02:56|
|Subject: Re: EXT :Re: Intermittent occurrence of ERROR: could not