From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
Cc: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, 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 19:56:54 |
Message-ID: | 6111.1491163014@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> writes:
> 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.
I think that we need just a relatively primitive facility in order
to meet that sort of need, but we do need something.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-04-02 19:57:41 | Re: Variable substitution in psql backtick expansion |
Previous Message | Fabien COELHO | 2017-04-02 19:50:59 | Re: Variable substitution in psql backtick expansion |