Re: [HACKERS] psql - add ability to test whether a variable exists - Mailing list pgsql-hackers
From | Fabien COELHO |
---|---|
Subject | Re: [HACKERS] psql - add ability to test whether a variable exists |
Date | |
Msg-id | alpine.DEB.2.20.1708261714010.17521@lancre Whole thread Raw |
In response to | Re: [HACKERS] psql - add ability to test whether a variable exists (Pavel Stehule <pavel.stehule@gmail.com>) |
Responses |
Re: [HACKERS] psql - add ability to test whether a variable exists
|
List | pgsql-hackers |
Hello Pavel, >> As a follow-up to the \if patch by Corey Huinker, here is a proposal to >> allow testing whether a client-side variable exists in psql. >> >> The syntax is as ugly as the current :'var' and :"var" things, but ISTM >> that this is the only simple option to have a working SQL-compatible syntax >> with both client-side substitution and server side execution. See the >> second example below. > > It is really ugly Yes, I agree:-) > - the ? symbol is not used in pair usually - so it is > much more visible - it is bad readable. Yep. > Maybe some other syntax: :{fx xxx} .. where fx can be one from more > possible operators ? ! ... Any colon prefixed syntax can be made to work because it is enough for the lexer to detect and handle... so :{defined varname} may be an option, although I do not like the space much because it adds some fuzzyness in the lexer which has to process it. It is probably doable, though. I like having a "?" because there is a question. Other suggestions somehow in line with your proposal could be :{?varname} :{varname?} what do you think? >> The other option would be to have some special keyword syntax, say >> "defined var", but then it would have to be parsed client side, and how to >> do that in an SQL expression is unclear, and moreover it would not look >> right in an SQL expression. If it would look like a function call, say >> "defined('var')", it would potentially interact with existing server-side >> user-defined functions, which is pretty undesirable. Hence the :?...? >> proposal above which is limited to variable subsitution syntax. > > should not be solved by introduction \ifdef ? This would be a client side only non extendable option: you can only test one variable at a time, you cannot say "NOT" or have to do \ifndef... CPP started like that and ended with #if bool-expr-with-defined in the end. The idea is to extend the newly added \if with client-side SQL-compatible expression syntax, and that the same syntax could be used server side with select, eg: -- client side \let i :j + 1 -- server side SELECT :j + 1 AS i \gset -- client-side conditional \if NOT :j > 1 OR... The colon prefixed substitution syntax already works for server side, but there is no way to check whether a variable exists which is compatible with that, hence this patch. Pgbench has expressions with patches to improve it, especially adding boolean operators. I think that the simplest plan is, when stabalized, to move the parser & executir to fe_utils and to use it from both psql et pgbench. Also I plan to add \if to pgbench, possibly by factoring some of the code from psql in fe_utils as well because it would help with benchmarks. Now given the patch queue length and speed I'm not even thinking of starting doing all this. -- Fabien.
pgsql-hackers by date: