Re: pg_dump 'die_on_errors'

Поиск
Список
Период
Сортировка
От Philip Warner
Тема Re: pg_dump 'die_on_errors'
Дата
Msg-id 6.1.1.1.0.20040812104259.059ab130@203.8.195.10
обсуждение исходный текст
Ответ на Re: pg_dump 'die_on_errors'  (Fabien COELHO <coelho@cri.ensmp.fr>)
Список pgsql-hackers
At 02:33 AM 12/08/2004, Fabien COELHO wrote:
>Maybe the time has come;-)

Sounds good to me. We've had the original behaviour since 7.1, I can 
understand there may be a desire to make it consistent with the 
carr-on-regardless behaviour of psql, but changing it in one release 
without the ability to revert to old behaviour is not ideal.

>BTW, Why is the default behavior such a pain?

I expect a script (shell, perl, or sql) to die when it hits an error; 
carr-on-regardless is IMO dangerous and just a hangover from piping to 
psql. One possible problem is illustrated by:
 - dump a db - use pg_restore in 'create' mode - for some reason DB creation fails

result: template1 (or other DB) ends up with junk. Or ends up with deleted 
tables if the initial connection was to a db with the same table names.

One of my motivations in doing the original pg_dump restructure and custom 
dump format was to allow for better error handling during a restore.



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 03 5330 3172          |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                 |    --________--
PGP key available upon request,  |  /
and from pgp.mit.edu:11371       |/ 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Philip Warner
Дата:
Сообщение: Re: pg_restore (libpq? parser?) bug in 8
Следующее
От: Philip Warner
Дата:
Сообщение: Re: pg_dump 'die_on_errors'