Re: [HACKERS] psql and libpq fixes
От | Brian E Gallew |
---|---|
Тема | Re: [HACKERS] psql and libpq fixes |
Дата | |
Msg-id | 200002101602.LAA18256@smtp3.andrew.cmu.edu обсуждение исходный текст |
Ответ на | Re: [HACKERS] psql and libpq fixes (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] psql and libpq fixes
Re: [HACKERS] psql and libpq fixes Re: [HACKERS] psql and libpq fixes |
Список | pgsql-hackers |
Then <tgl@sss.pgh.pa.us> spoke up and said: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> This does bring up a thought --- should psql's kill-the-script-on-error > >> option perhaps zap the script only for errors committed outside of a > >> transaction block? > > But on third thought, probably the thing that would be really useful > for "expected errors" is if there is a backslash-command that turns on > or off the kill-on-error behavior. (The command line switch would > merely set the initial state of this flag.) This way, a script could > use the option in an intelligent fashion: Urhm, wouldn't a better idea be to have something like Ingres' "ON ERROR" and "ON WARNING" settings? In Ingres esqlc, you can create functions and then tell Ingres to execute them in the even of a warning or error. Also, you can say "ON ERROR CONTINUE" and errors will then be returned to the application as a status, but otherwise ignored. -- ===================================================================== | JAVA must have been developed in the wilds of West Virginia. | | After all, why else would it support only single inheritance?? | ===================================================================== | Finger geek@cmu.edu for my public key. | =====================================================================
В списке pgsql-hackers по дате отправления: