Re: Undefined psql variables

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Undefined psql variables
Date: 2017-04-08 19:34:39
Message-ID: CAFj8pRDmbcxy1mrVMFQ9UabB2QSLZmOut7v_KMRnVWssCHJ=UQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

>
> Hello Pavel,
> n
>
>> you proposal disallow client side expressions.
>>
>
> I do agree that some client side expressions are necessary. I do not want
> to disallow them.
>
> I agree so is not possible to mix server side and client side expressions.
>>
>
> My point is that a minimal of cross-support is possible.
>
> But I am sceptic so benefit of server side expression is higher than a
>> lost of client side expressions.
>>
>
> There is a misunderstanding. I am not against client side expression. I do
> want to allow the same server & client side capabilities suggested by Tom,
> I'm just arguing about the syntax, to avoid a prefix oriented approach.
>
> If we disallow server side expressions, then your examples are only two
>> lines longer, but the implementation can be more simpler.
>>
>> SELECT version FROM app_version
>> \gset
>> \if :version >= 2.0
>> ...
>>
>> Still I don't think so server side expression in \if is good idea.
>>
>
> Ok, so you do not like server-side expression capabities integrated to
> \if. I understood that you were in favor of Tom's proposal.
>

In this moment I see difficult implementation of \if expressions if we
should to separate server side and client side expressions. The prefix
oriented approach is used well in PLpgSQL

FOR IN SELECT, FOR IN ARRAY, FOR IN 1..x

Tom's design should be more simply for implementation and can be simply
extended. There is clean if expr is client side or server side.

>
> From a semantical point of view they are not necessary because the same
> effect can be obtained through \gset, at the price of an intermediate
> variable. So the server-side thing is just a syntax convenience. I think
> that independently of whether they are added, Tom's point is that it should
> be possible to add those features later on, hence the discussion about a
> design.

We are talking about primitive scripting language - that should be simple
how it is possible. One command more, or performance there are not
important - if the performance will not be terrible. The overhead of
intermediate variable is +/- zero against remote expression. But back to
main issue. We should to find syntax if some variable is defined and can be
used or not.

Maybe the solution should not be directly joined with \if command.

what do you think about special \set command, that can be active only when
variable is not defined.

some like

\setifempty xxx default

Regards

Pavel

>
>
> --
> Fabien.
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-04-08 19:57:25 Re: [sqlsmith] Planner crash on foreign table join
Previous Message Andrew Dunstan 2017-04-08 18:49:10 Re: Fwd: Re: Running make check-world in buildfarm (was Re: [COMMITTERS] pgsql: Use SASLprep to normalize passwords for SCRAM authentication.)