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.


  SELECT ... \gset


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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to