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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: [HACKERS] sequence data type
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Subtle bug in "Simplify tape block format" commit