Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
От | Fabien COELHO |
---|---|
Тема | Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless) |
Дата | |
Msg-id | alpine.DEB.2.20.1701301816290.30145@lancre обсуждение исходный текст |
Ответ на | Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands: \quit_if, \quit_unless) ("Daniel Verite" <daniel@manitou-mail.org>) |
Список | pgsql-hackers |
Hello Daniel, > [...] So psql is not following that model with ON_ERROR_STOP if it exits > with an error when unable to evaluate an "if" expression. I'm not > implying that we should necessarily adopt the shell behavior, but as > these choices have certainly been made in POSIX for good reasons, we > should make sure to think twice about why they don't apply to psql. Interesting point. The shell is about processes, and if relies on the status code returned, with 0 meaning true, and anything else, which is somehow a process error, meaning false. So there is no way to distinguish false from process error in this system, because the status is just one integer. However, a syntax error, for instance with a shell internal test, leads to nothing being executed: bash> if [[ bad syntax ]] ; then echo then ; else echo else ; fi -bash: conditional binary operator expected -bash:syntax error near `syntax' # nothing is echoed Another example with python in interactive mode: python> if 1+: print 1; else print 0 SyntaxError: invalid syntax # nothing is printed So rejecting execution altogether on syntax errors is somehow a common practice. -- Fabien.
В списке pgsql-hackers по дате отправления: