default to to ON_ERROR_STOP=on (Re: psql: exit status with multiple -c and -f)
| От | Justin Pryzby |
|---|---|
| Тема | default to to ON_ERROR_STOP=on (Re: psql: exit status with multiple -c and -f) |
| Дата | |
| Msg-id | 20211227161021.GO17618@telsasoft.com обсуждение исходный текст |
| Ответ на | psql: exit status with multiple -c and -f (Justin Pryzby <pryzby@telsasoft.com>) |
| Ответы |
Re: default to to ON_ERROR_STOP=on (Re: psql: exit status with multiple -c and -f)
Re: default to to ON_ERROR_STOP=on (Re: psql: exit status with multiple -c and -f) |
| Список | pgsql-hackers |
On Mon, Dec 06, 2021 at 09:08:56AM -0600, Justin Pryzby wrote: > I raised this issue a few years ago. > https://www.postgresql.org/message-id/20181217175841.GS13019%40telsasoft.com > > |[pryzbyj@database ~]$ psql -v VERBOSITY=terse ts -xtc 'ONE' -c "SELECT 'TWO'"; echo "exit status $?" > |ERROR: syntax error at or near "ONE" at character 1 > |?column? | TWO > | > |exit status 0 > > The documentation doen't say what the exit status should be in this case: > | psql returns 0 to the shell if it finished normally, 1 if a fatal error of its own occurs (e.g., out of memory, filenot found), 2 if the connection to the server went bad and the session was not interactive, and 3 if an error occurredin a script and the variable ON_ERROR_STOP was set. > > It returns 1 if the final command fails, even though it's not a "fatal error" > (it would've happily kept running more commands). > > | x=`some_command_that_fails` > | rm -fr "$x/$y # removes all your data > > | psql -c "begin; C REATE TABLE newtable(LIKE oldtable) INSERT INTO newtable SELECT * FROM oldtable; commit" -c "DROP TABLEoldtable > | psql -v VERBOSITY=terse ts -xtc '0CREATE TABLE newtbl(i int)' -c 'INSERT INTO newtbl SELECT * FROM tbl' -c 'DROP TABLEIF EXISTS tbl' -c 'ALTER TABLE newtbl RENAME TO tbl'; echo ret=$? > > David J suggested to change the default value of ON_ERROR_STOP. The exit > status in the non-default case would have to be documented. That's one > solution, and allows the old behavior if anybody wants it. That probably does > what most people want, too. This is more likely to expose a real problem that > someone would have missed than to break a legitimate use. That doesn't appear > to break regression tests at all. I was wrong - the regression tests specifically exercise failure cases, so the scripts must continue after errors. I think the current behavior of the regression test SQL scripts is exactly the opposite of what's desirable for almost all other scripts. The attached makes ON_ERROR_STOP the default, and runs the regression tests with ON_ERROR_STOP=0. Is it viable to consider changing this ?
Вложения
В списке pgsql-hackers по дате отправления: