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.1702100847180.27011@lancre обсуждение исходный текст |
Ответ на | Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless) (Corey Huinker <corey.huinker@gmail.com>) |
Ответы |
Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
|
Список | pgsql-hackers |
Hello Corey, > Changes in this patch: > > - invalid boolean expression on \if or \elif is treated as if the script > had a bad \command, so it either stops the script (ON_ERROR_STOP, script > mode), or just gives the ParseVariableBool error and continues. > > - All interactive "barks" removed except for [...] > > - remaining error messages are tersed: [...] Patch applies, make check ok, psql tap test ok. Yep. At least the code is significantly simpler. There is a useless space on one end of line in the perl script. Shouldn't there be some documentation changes to reflect the behavior on errors? A precise paragraph about that would be welcome, IMHO. In particular, I suggest that given the somehow more risky "ignore and keep going whatever" behavior after a syntax error on if in a script, there should be some advice that on_error_stop should better be activated in scripts which use \if. Given that there is no more barking, then having some prompt indication that the code is inside a conditional branch becomes more important, so ISTM that there should be some plan to add it. -- Fabien.
В списке pgsql-hackers по дате отправления: