2016-12-03 8:16 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.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,



> --
> Fabien.

Reply via email to