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 по дате отправления:

Предыдущее
От: "Christopher Kings-Lynne"
Дата:
Сообщение: Re: db partial dumping with pg_dump
Следующее
От: "Christopher Kings-Lynne"
Дата:
Сообщение: tsearch vs. fulltextindex