Re: PSQL commands: \quit_if, \quit_unless

Hello,

> My guess is that something comparable to where pgbench is would be a
> reasonable target --- not least because I think we should strive to
> reduce unnecessary differences between psql and pgbench metalanguages.
>
> I'm not sure that I'm ready to propose that they should share the same
> expression engine, but perhaps it's not a totally wacky idea.

I'm trying to summarize a proposal for a conditional structure:

- existing psql ":"-variables can be used, allowing anything from SQL
(eg querying about available objects, features, extensions,
current settings...)

- target psql conditional syntax could be:

\if <expression>
...
\elif <...>
...
\else
...
\endif

- possible incremental implemention steps on this path:

(1) minimal condition and expression, compatible with
a possible future full-blown expression syntax

\if :variable
\if not :variable -- maybe \if ! :variable
...
\endif

(2) add "\else"

(3) add "\elif ..." (or maybe "\elsif ..."?)

(4) add greater but limited expressions, compatible with a full blown
expression syntax (eg \if :var/const <comparison-operator> :var/const)

(5) add full-blown <expression> support for \if, which suggest that
it would also be available for \set

Does this looks okay, or does it need to be amended?

A few comments:

Given the experience with pgbench and the psql context, I do not think
that it would really need to go beyond step 2 above, but I agree that I
may be wrong and it is best to be prepared for that from the start. Given
the complexity and effort involved with (5), it seems wise to wait for a
clearer motivation with actual use-cases before going that far.

In the benchmarking context, the point is to test performance for a
client-server scenario, in which case the client has to do some things,
thus needs miminal computation capabilities which were available early in
pgbench (\setrandom, \set with one arithmetic operation...) because they
were necessary. Probably \if ... would make sense in pgbench, so I'll
think about it.

In psql interactive context, conditions and expressions do not make sense
as the user typing the command knows what they want, thus will do
evaluations in their head to avoid typing stuff...

In psql scripting context, conditions are likely to be about what to do
with the database, and what I understand of the use-case which started
this discussion is that it is about versions, settings, available objects,
typically "if this is already installed, skip this part" or "if version
beyond YYY, cannot install because of missing features" when installing
and initializing an application. For this purpose, ISTM that the query is
necessarily performed server-side, thus the actual need for a full-blown
client-side expression is limited or void, although as already said being
prepared is a good thing.

--
Fabien.