Re: Undefined psql variables

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.