Hi 2018-03-03 13:32 GMT+01:00 Pavel Stehule <pavel.steh...@gmail.com>:
> > > 2018-03-03 11:35 GMT+01:00 Fabien COELHO <coe...@cri.ensmp.fr>: > >> >> Hello devs, >> >> This is a discussion without actual patch intended for pg12, to be added >> to CF 2018-09. The expected end result is either "returned with feedback", >> meaning proceed to send some big patch(es), or "rejected", meaning the >> project does not want this, no point in submitting something. >> >> Client "psql" has an "\if" which can test a boolean value and has >> ":"-prefixed variables, including special presets such as ":VERSION_NUM" >> and ":SERVER_VERSION_NUM". >> >> The features are already usable because one can do server-side >> expressions (if connected), which is a little cumbersome and ugly but >> nevertheless functional, eg: >> >> SELECT :VERSION_NUM = :SERVER_VERSION_NUM AS "same_version" \gset >> \if :same_version >> ... >> >> However, when the "\if" patch was discussed, there was the underlying >> idea to extend psql so as to add client-side expression. That would allow >> things like: >> >> \let i <some arithmetic or logical expression...> >> \if :VERSION_NUM = :SERVER_VERSION_NUM >> ... >> >> Before eventually starting on this subject with a loose objective of >> targeting 12.0, I would like to ascertain, especially from committers, but >> also from others, that: >> >> (1) the objective is desirable (i.e. avoid ending with "we do not want >> this feature on principle, the cost-benefit balance is not good >> enough"). >> >> (2) maybe have a feedback on the proposed changes (not necessarily >> distinct patches, opinions are welcome), which would be to: >> (a) extend pgbench expressions so that they can handle what >> psql can do (eg variable-exists test which are available in psql) >> (b) maybe do some preliminary refactoring (eg create >> "pgbench/expression.c", "pgbench/variable.c") >> (c) move the pgbench expression engine to fe-utils >> (lexer, parser, execution...), >> (d) do some renaming (eg some "feex" prefix for "front-end >> expressions" to the various functions & types?), >> (e) abstract pgbench and psql variables so that they can be used >> transparently by expressions (i.e. some API alignment) >> (f) connect the engine to "psql" >> (g) create a shared documentation about these expressions, >> referenced from both psql and pgbench documentations. >> (h) provide non-regression tests on psql side as well. >> >> The overall transformation would be quite large (about 2000 lines moved >> around) but "quite" simple (it is moving an existing, working and tested >> feature to allow using it elsewhere), not a lot of new code per se. >> > > I understand the request of some simple expression evaluation for pgbench > and conditional execution for psql. Because syntax is same, then share code > is really good idea. Lexer, parser, variable processing should be moved to > fe-utils, other implemented on place. We don't need all commands of pgbench > in psql, and we don't need interactive loop and psql commands in pgbench. > But the syntax of input commands is same on both environments, and all on > this level can be shared via some library. Some shared commands can be > implemented in other library, and called from final positions. > > Using some simple expressions evaluations is much more simple, then > integration some full functional VM like lua, Python - and still good > enough. > > I have not the feedback from psql users about missing strong integrated > language. What is current weak place of psql is tab complete and readline > multiline editor. The pgcli is better - and second hand, everything else is > better in psql. > please, can you port expression evaluation from pgbench to psql? I miss a patch. I am sure so psql expression evaluation has strong benefit - mainly for expressions like \if SERVER_VERSION_NUM >= xxxx \endif Regards Pavel Regards Pavel > Regards > > Pavel > >> >> -- >> Fabien. >> >> >
