Re: PSQL commands: \quit_if, \quit_unless

Hello Tom,

>> So I think it would be reasonable for somebody to implement \if,
>> \elseif, \endif first, with the argument having to be, precisely, a
>> single variable and nothing else (not even a negator). [...]

> This seems like a reasonable implementation plan to me, not least because
> it tackles the hard part first. There's no doubt that we can build an
> expression evaluator, but I'm not entirely sure how we're going to wedge
> conditional eval or loops into psql's command reader.
>
> (Or in other words, let's see \while ... \endloop in the minimal proposal
> as well, or at least a sketch of how to get there.)

My 0.02 €:

I have not seen any use case for a loop... Does someone have something
convincing? I could think of some use in benchmarking (aka in pgbench),
but not psql... But I may lack imagination.

If one realistic case is found, then from a syntactic point of view
"\while expr ... \endwhile/loop/whatever" looks straightforward enough.

However, the implementation issues are pretty different from "if" which
can be managed pretty simply on the fly with a stack and a little
automaton. A loop needs to store its body and evaluate it over and over,
which means having processed the input up to the end of the loop before
proceeding, including nesting and so... it is a much less interactive
friendly construct.

Note that although "cpp" has an if, but it does not have any loop.

In my opinion psql should stay at that same simple level: ISTM that the
typical psql-script requirement is to be able to test some things, eg for
installing or upgrading the schema of an application, and for that
variables, expressions server side and maybe client side, and conditions
are mostly enough. A lot of "IF EXISTS" added to many commands recently
are motivated to handle this kind of use-case at the command per command
level, which is not necessarily the right place.

A while loops turns a simple thing into a potential Turing-complete beast,
without a strong incentive I think that it should be avoided.

--
Fabien.