Re: Variable substitution in psql backtick expansion

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Daniel Verite <daniel(at)manitou-mail(dot)org>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Variable substitution in psql backtick expansion
Date: 2017-04-04 08:09:20
Message-ID: CAFj8pRCX99nNGTMONJ_6z-T4L0MfJv+KiqvEwsdO44vA0mY7LA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2017-04-04 9:53 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> Hello Pavel,
>
> The expression evaluation is interesting question, but there is a
>> workaround - we can use \gset already.
>>
>
> Yes, that is a good point. It is a little bit inconvenient because it
> requires a dummy variable name each time for testing.
>
> SELECT whatever AS somename \gset
> \if :somename
>
> But this is an already functional solution to use server-side expressions,
> so there is no hurry.
>
> What is more important, because there is not any workaround, is detection
>> if some variable exists or not.
>>
>> So possibilities
>>
>> 1. \if defined varname
>>
>
> Yep, and as Tom pointed it should handle NOT as well.
>
> My issue with this version is that Lane Tom convinced me some time ago
> that client side expressions should look like SQL expressions, so that
> everything in the script is somehow in the same language. I think that he
> made a good point.
>
> However "defined varname" is definitely not an SQL expression, so I do not
> find that "intuitive", for a given subjective idea of intuitive.
>
> Then there is the question of simple comparisons, which would also make
> sense client-side, eg simple things like:
>
> \if :VERSION_NUM >= 110000
>
> Should not need to be executed on the server.
>
> 2. \ifdefined or \ifdef varname
>>
>
> I think that we want to avoid that if possible, but it is a cpp-like
> possibility. This approach does not allow to support comparisons.
>
> 3. \if :?varname
>>
>
> Tom suggested that there is a special namespace problem with this option.
> I did not understand what is the actual issue.
>
> I like first two, and I can live with @3 - although it is not intuitive
>>
>
> For me @3 is neither worth nor better than the already existing :'varname'
> and :"varname" hacks, it is consistent with them, so it is just an
> extension of the existing approach.
>
> It seems easy to implement because the substitution would be handled by
> the lexer, so there is no need for anything special like looking at the
> first or second word, rewinding, whatever.
>
> Basically I agree with everything Tom suggested (indeed, some client side
> definition & comparison tests are really needed), but not with the proposed
> prefix syntax because it does not look clean and SQL.

I don't need a full SQL expression in \if commands ever. I prefer some
simple functional language here implemented only on client side - the code
from pgbench can be used maybe

\if fx( variable | constant [, ... ] )

the buildin functions can be only basic

defined, undefined, equal, greater, less

\if defined(varname)
\if geq(VERSION_NUM, 11000)

But this question is important - there is not a workaround

postgres=# select :xxx
postgres-# ;
ERROR: syntax error at or near ":"
LINE 1: select :xxx
^
postgres=# \if :xxx
unrecognized value ":xxx" for "\if expression": boolean expected
postgres(at)#

>
>
> --
> Fabien.
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2017-04-04 08:41:57 WIP: Aggregation push-down
Previous Message David Rowley 2017-04-04 07:55:34 Re: multivariate statistics (v25)