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.