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:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Variable substitution in psql backtick expansion
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Build failure on thrips