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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
