Re: Table data exclusion patch for pg_dump

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Vadim Trochinsky <me(at)vadim(dot)ws>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Table data exclusion patch for pg_dump
Date: 2009-05-01 19:40:59
Message-ID: 162867790905011240j143d160bw505b19cf865cea61@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2009/5/1 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Andrew Dunstan <andrew(at)dunslane(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-05-01 19:41:42 Re: Throw some low-level C scutwork at me
Previous Message Joshua D. Drake 2009-05-01 19:37:19 Re: Throw some low-level C scutwork at me