From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Josh Kupershmidt <schmiddy(at)gmail(dot)com> |
Cc: | "Karl O(dot) Pinc" <kop(at)meme(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Suggestion for --truncate-tables to pg_restore |
Date: | 2012-11-26 18:06:56 |
Message-ID: | CA+TgmoY7MZatD7qiR97hQDOz-Pxg+vaKmrKXdm36=RS=mtH58A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 21, 2012 at 12:53 AM, Josh Kupershmidt <schmiddy(at)gmail(dot)com> wrote:
> TBH, I didn't find the example above particularly compelling for
> demonstrating the need for this feature. If you've just got one table
> with dependent views which needs to be restored, it's pretty easy to
> manually TRUNCATE and have pg_restore --data-only reload the table.
> (And easy enough to combine the truncate and restore into a single
> transaction in case anything goes wrong, if need be.)
>
> But I'm willing to grant that this proposed feature is potentially as
> useful as existing restore-jiggering options like --disable-triggers.
> And I guess I could see that if you're really stuck having to perform
> a --data-only restore of many tables, this feature could come in
> handy.
I think I would come down on the other side of this. We've never
really been able to get --clean work properly in all scenarios, and it
seems likely that a similar fate will befall this option.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-11-26 18:14:52 | Re: [WIP] pg_ping utility |
Previous Message | Merlin Moncure | 2012-11-26 18:05:18 | Re: WIP json generation enhancements |