Re: Undefined psql variables - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Undefined psql variables
Date
Msg-id 6111.1491163014@sss.pgh.pa.us
Whole thread Raw
In response to Re: Undefined psql variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.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



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Variable substitution in psql backtick expansion
Next
From: Fabien COELHO
Date:
Subject: Re: Variable substitution in psql backtick expansion