Re: db partial dumping with pg_dump - Mailing list pgsql-hackers

From Tom Lane
Subject Re: db partial dumping with pg_dump
Date
Msg-id 4580.1029299515@sss.pgh.pa.us
Whole thread Raw
In response to Re: db partial dumping with pg_dump  (Scott Shattuck <ss@technicalpursuit.com>)
List pgsql-hackers
Scott Shattuck <ss@technicalpursuit.com> writes:
> I'd also kill for pg_restore --ignore-existing-objects .... so I could
> run the darn thing against a database that's already got pl/pgsql
> installed in template1 and the dump file wants to install it again etc.

In general, I think it's a mistake for pg_restore to bail out on errors.
The underlying pg_dump scripts have been built and optimized on the
assumption that psql would keep plugging after seeing an error.  For
example, scripts containing "\connect - foo" still work if there's no
"foo" user ... but only because psql doesn't go belly-up.  pg_restore
is way less forgiving.

I think the ideal behavior for pg_restore would be to abandon work on
the current dump item upon seeing a SQL error, but to pick up with the
next one.  (Of course we could have an --anal-retentive switch to bail
on first error, but I doubt it'd be used much.)  Errors associated with
ownership switches shouldn't cause failure in any case.

Anybody care to submit patches to make this happen?
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Re: db partial dumping with pg_dump
Next
From: "Christopher Kings-Lynne"
Date:
Subject: tsearch vs. fulltextindex