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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Undefined psql variables
Date: 2017-04-02 17:02:05
Message-ID: CAFj8pRDqnjyQ96RwEb9EDvNfbOiZ5Yefrac7BWX=mzViQ5CmFg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

>
> Hello Tom,
>
> I'm inclined to suggest that we should require all extensions beyond the
>> boolean-literal case to be set up as a keyword followed by appropriate
>> argument(s); that seems like it's enough to prevent syntax conflicts from
>> future additions. So you could imagine
>>
>> \if defined varname
>> \if sql boolean expression to send to server
>> \if compare value operator value
>>
>> It would be easy to allow "not" in front of any one of these, but
>> it's less clear how to do AND or OR combinations. You can always
>> fake AND with nested \if's, but OR is a bit more of a problem.
>> Maybe we don't need it.
>>
>> Other ideas about how to design this?
>>
>
> My 0.02 €:
>
> I have convinced myself that, unlike pgbench, psql does not really need an
> advanced client-side-implemented language, so the smaller the better. What
> I mean by this is that from psql point of view it is ok that the actual
> expression evaluation is performed server-side. From a user experience
> point of view it would look similar to pgbench, just the evaluator does not
> need to be client-side.
>

I am sorry - I disagree - I don't expect hard scripting in psql too. But
psql is much more widely used than pgbench - and scripting should be
intuitive.

Regards

Pavel

>
> So I would suggest something close but maybe simpler than what you suggest
> above. If there is just one thing, it is true or false, checked client
> side, well, this is already implemented:-).
>
> \if something
>
> If there are more than one argument, or maybe if previous true/false
> evaluation failed, then:
>
> \if sql expression to be evaluated server side
>
> Then the result is checked for true or false client-side. It would be
> equivalent to:
>
> SELECT sql expression to be evaluted server side AS is_ok \gset
> \if :is_ok
>
> Finally I would suggest that client to server would only communicate by
> variable substitution, as the backtick patch with external processes.
>
> For checking variable definition, I would suggest to extend the variable
> access syntax so that there is no exception to the one thing rule between
> client side and server side evaluation:
>
> \if :?variable
>
> the :?... is subsituted by true or false depending on whether the variable
> exists.
>
> \if NOT :?variable
>
> would work by executing "NOT ..." on the server. No need for "defined"
> which would not look like SQL function calls anyway, no need for any
> operator client side or clumsy rules.
>
> --
> Fabien.
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2017-04-02 17:36:52 Re: Variable substitution in psql backtick expansion
Previous Message Pavel Stehule 2017-04-02 17:00:24 Re: Undefined psql variables