Re: PSQL commands: \quit_if, \quit_unless

2016-12-03 8:16 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

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

Some possibilities from pgbench can have sense in psql too - generating
some random numbers from a range. In the end we use one parser for psql
and for pgbench.

I agree, so step 2 should be enough, and I accept so there is opened door
for any future enhancing.

We can implement some client side boolean functions (similar to pgbench
functions that can cover often tasks: version_less, version_greather,
user_exists, tables_exists, index_exists, variable_exists, schema_exists,

Regards

Pavel

>
> --
> Fabien.
>