Re: Undefined psql variables - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: Undefined psql variables
Date
Msg-id alpine.DEB.2.20.1704022158480.9265@lancre
Whole thread Raw
In response to [HACKERS] Undefined psql variables  (Corey Huinker <corey.huinker@gmail.com>)
List pgsql-hackers
Hello Tom,

>> I'm just arguing that for pgbench the evaluator needs to be on the client
>> side, which implies a lexer, parser and executor. For psql, it does not
>> really matter where the evaluator is, thus relying on the server should be
>> fine and simpler and also powerful, provided the necessary information can
>> be transfered from the client, eg through variable expansion, and maybe
>> back in the form of special variables to test for errors for instance.
>
> I don't really buy this.  Certainly it'd be fine for many use-cases, but 
> there will be cases where what you're trying to script around is 
> server-side errors. An expression evaluation facility that goes belly-up 
> as soon as the server is in an aborted transaction is not going to be 
> very useful in that scenario.

"Going belly-up" suggests testing/checking for errors, which could be 
eased through special variables à la errno and more than simplistic 
client-side expression evaluation.

> I think that we need just a relatively primitive facility in order
> to meet that sort of need, but we do need something.

Hmmm. Yes, I was thinking of that kind of thing. The question is how large 
the necessary "something". I'm arguying for the smallest possible 
solution. Maybe handling direct booleans (as already implemented) and the 
NOT operator could be enough (clear enough to understand for the user, 
would cover needed cases, and would be easy to implement)? i.e.
  \if NOT :IS_CONNECTED    ...
  SELECT ... \gset  \if :SQL_ERROR_OCCURED    ...
  \if :CURRENT_TRANSACTION_ABORTED    ...

> So my view of this is that "send the expression to the server" ought
> to be just one option for \if, not the only way to do it.  Hence my
> suggestion of "\if sql ...text to send to server...".  Probably someone
> can think of a better keyword than "sql" for that.

That is the kind of (ugly) thing I would really like to avoid, if 
possible. As pavel argued, it should be "intuitive", and having a explicit 
syntactic marker and/or possibly two distinct syntaxes does not strike me 
as a desirable user-experience.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Suggested fix for \p and \r in psql
Next
From: Jan Michálek
Date:
Subject: Re: Other formats in pset like markdown, rst, mediawiki