Scott Shattuck <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
