Desirability of client-side expressions in psql? - Mailing list pgsql-hackers

From Fabien COELHO
Subject Desirability of client-side expressions in psql?
Date
Msg-id alpine.DEB.2.20.1803031056130.12500@lancre
Whole thread Raw
Responses Re: Desirability of client-side expressions in psql?  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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.

-- 
Fabien.


pgsql-hackers by date:

Previous
From: Joe Conway
Date:
Subject: Re: public schema default ACL
Next
From: John Naylor
Date:
Subject: Re: WIP: a way forward on bootstrap data