Re: PSQL commands: \quit_if, \quit_unless - Mailing list pgsql-hackers

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.