From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Scott Shattuck <ss(at)technicalpursuit(dot)com> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>, Rod Taylor <rbt(at)zort(dot)ca>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: db partial dumping with pg_dump |
Date: | 2002-08-14 04:31:55 |
Message-ID: | 4580.1029299515@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Scott Shattuck <ss(at)technicalpursuit(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2002-08-14 04:37:56 | tsearch vs. fulltextindex |
Previous Message | Christopher Kings-Lynne | 2002-08-14 04:30:47 | Re: db partial dumping with pg_dump |