Re: Desirability of client-side expressions in psql?

Hi

2018-03-03 13:32 GMT+01:00 Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>:

>
>
> 2018-03-03 11:35 GMT+01:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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.
>>
>>
>