Re: Table data exclusion patch for pg_dump - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: Table data exclusion patch for pg_dump
Date
Msg-id 162867790905011240j143d160bw505b19cf865cea61@mail.gmail.com
Whole thread Raw
In response to Re: Table data exclusion patch for pg_dump  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2009/5/1 Tom Lane <tgl@sss.pgh.pa.us>:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Tom Lane wrote:
>>> Why wouldn't you just use -s ?
>
>> You might want the whole schema and data for most but not all of the
>> tables (e.g. you might leave out a large session table for a web app).
>
> The use-case seems pretty thin to me, and the potential for shooting
> oneself in the foot rather large.  We routinely get complaints, for
> example, from people who do partial dumps and then find out they don't
> restore because of foreign key constraints.  This looks like mostly
> a larger-gauge version of that.

I am sorry, but this use-case is relative maybe often. When we
migrated from 8.1 to 8.3 we truncates all large audit and log tables.
Without this switch we had to use TRUNCATE or own substitution of
pg_dump. I thing so this switch should be implement like TRUNCATE
statement - you have to exclude all depended tables.

regards
Pavel Stehule

>
>                        regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Throw some low-level C scutwork at me
Next
From: Tom Lane
Date:
Subject: Re: Table data exclusion patch for pg_dump