Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)

Поиск
Список
Период
Сортировка
От Corey Huinker
Тема Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)
Дата
Msg-id CADkLM=fPrnnmmkt4whSXmhoC_UMjvdvC2RAaX0XLneqZhzKmDA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Ответы Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)  (Fabien COELHO <coelho@cri.ensmp.fr>)
Re: \if, \elseif, \else, \endif (was Re: [HACKERS] PSQL commands:\quit_if, \quit_unless)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Fri, Feb 3, 2017 at 7:24 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:

Hello Erik,

Still, it would be an improvement to be able to break out of an inactive \if-branch with Ctrl-C.

Yes.

'\endif' is too long to type, /and/ you have to know it.

Yep. \if is shorter but has been rejected. Ctrl-C should be the way out.

I could bulk up the error message on if/elif like such:

if: true, executing commands.
if: false, ignoring commands until next \else, \elif, or \endif.
if: error, ignoring all commands until next \endif
else: true, executing commands
else: false, ignoring commands until next \endif
else: error, ignoring commands until next \endif
endif: now executing commands
endif: ignoring commands until next [\else, [\elif [, \endif]]

Basically, I'd tailor the message to as closely reflect what is possible for the user at this moment.


Can anyone think of a reason why Ctrl-C would be a bad idea? If not I'll start looking into it, as I'm not presently aware of what it is used for.


2. Inside an \if block \q should be given precedence and cause a direct exit of psql (or at the very least exit the if block(s)), as in regular SQL statements (compare: 'select * from t \q' which will immediately exit psql -- this is good. )

One use case if to be able to write "\if ... \q \endif" in scripts. If \q is always executed, then the use case is blown. I cannot think of any language that would execute anything in a false branch. So Ctrl-C or Ctrl-D is the way out, and \if control must really have precedence over its contents.

3. I think the 'barking' is OK because interactive use is certainly not the first use-case.
But nonetheless it could be made a bit more terse without losing its function.

[...] It really is a bit too wordy, [...]

Maybe.

(or alternatively, just  mention 'if: active' or 'elif: inactive', etc., which has the advantage of being shorter)

This last version is too terse I think. The point is that the user understands whether their commands are going to be executed or ignored, and "active/inactive" is not very clear.

5. A real bug, I think:
#\if asdasd
unrecognized value "asdasd" for "\if <expr>": boolean expected
# \q;
inside inactive branch, command ignored.
#

That 'unrecognized value' message is fair enough but it is counterintuitive that after an erroneous opening \if-expression, the if-modus should be entered into. ( and now I have to type \endif again... )

Hmmm.

It should tell that it is in an unclosed if and that it is currently ignoring commands, so the "barking" is missing.

It does need a bespoke bark.

Also, I do not think that implementing a different behavior for interactive is a good idea, because then typing directly and reading a file would result in different behaviors, which would not help debugging.

+1
 

So, as Tom suggested (I think), the feature is not designed for interactive use, so it does not need to be optimized for that purpose,
although it should be sane enough.

+1
 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: pageinspect: Try to fix some bugs in previous commit.