Re: [HACKERS] psql - add ability to test whether a variable exists
| От | Fabien COELHO |
|---|---|
| Тема | Re: [HACKERS] psql - add ability to test whether a variable exists |
| Дата | |
| Msg-id | alpine.DEB.2.20.1708261714010.17521@lancre обсуждение исходный текст |
| Ответ на | Re: [HACKERS] psql - add ability to test whether a variable exists (Pavel Stehule <pavel.stehule@gmail.com>) |
| Ответы |
Re: [HACKERS] psql - add ability to test whether a variable exists
|
| Список | 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 по дате отправления: