Re: db partial dumping with pg_dump
От | Tom Lane |
---|---|
Тема | Re: db partial dumping with pg_dump |
Дата | |
Msg-id | 4580.1029299515@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: db partial dumping with pg_dump (Scott Shattuck <ss@technicalpursuit.com>) |
Список | 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 по дате отправления: