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 |/
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
