Re: Undefined psql variables

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

In response to

Responses

Browse pgsql-hackers by date

  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