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
>
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 |