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

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Erik Rijkers <er(at)xs4all(dot)nl>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org
Subject: Re: \if, \elseif, \else, \endif (was Re: PSQL commands: \quit_if, \quit_unless)
Date: 2017-02-03 12:24:22
Message-ID: alpine.DEB.2.20.1702031300100.4856@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

> 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.

Otherwise that is really the currently desired behavior for scripting use:

\if syntax-error...
DROP USER foo;
\elif ...
DROP DATABASE foo;
\else
...
\endif

If the "\if" is simply ignored, then it is going to execute everything
that appears after that, whereas the initial condition failed to be
checked, and it will proceed to ignore all further \elif and \else in
passing.

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.

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.

--
Fabien.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Neha Sharma 2017-02-03 12:26:59 Re: Gather Merge
Previous Message Tomas Vondra 2017-02-03 12:15:16 Re: Checksums by default?