Re: Suggestion for --truncate-tables to pg_restore

From: "Karl O(dot) Pinc" <kop(at)meme(dot)com>
To: Josh Kupershmidt <schmiddy(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Suggestion for --truncate-tables to pg_restore
Date: 2012-12-05 04:40:29
Message-ID: 1354682429.2831.0@mofo
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 12/04/2012 09:26:47 PM, Josh Kupershmidt wrote:
> Sorry for the delay in following up here.

No problem at all.

> Well, as far as I was able to tell, the use-case where this patch
> worked without trouble was limited to restoring a table, or schema
> with table(s), that:
> a.) has some view(s) dependent on it
> b.) has no other tables with FK references to it, so that we don't
> run into:
> ERROR: cannot truncate a table referenced in a foreign key
> constraint
> c.) is not so large that it takes forever for data to be restored
> with indexes and constraints left intact
> d.) and whose admin does not want to use --clean plus a list-file
> which limits pg_restore to the table and its views
> I was initially hoping that the patch would be more useful for
> restoring a table with FKs pointing to it, but it seems the only
> reliable way to do this kind of selective restore with pg_restore is
> with --clean and editing the list-file. Editing the list-file is
> certainly tedious and prone to manual error, but I'm not sure this
> particular patch has a wide enough use-case to alleviate that pain
> significantly.

I think there must be a reliable way to restore tables with FKs
pointing to them, but getting pg_restore to do it seems perilous; at
least given your expectations for the behavior of pg_restore in the
context of the existing option set.

As with you, I am not inclined to add another option to pg_restore
unless it's really useful. (Pg_restore already has gobs of options,
to the point where it's getting sticky.) I don't think this
patch meets the utility bar. It might be able to be re-worked into
something useful, or it might need to evolve into some sort of new
restore utility per your thoughts. For now better to reject it until
the right/comprehensive way to proceed is figured out.

Thanks for all your work. I hope that this has at least
moved the discussion forward and not been a waste of everybody's
time. I would like to see a "better" way of restoring
tables that are FK reference targets.


Karl <kop(at)meme(dot)com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Phil Sorber 2012-12-05 05:46:37 Re: [WIP] pg_ping utility
Previous Message Josh Kupershmidt 2012-12-05 03:26:47 Re: Suggestion for --truncate-tables to pg_restore