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, Regards Pavel > > -- > Fabien. >
