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