Re: Undefined psql variables

Corey Huinker <corey(dot)huinker(at)gmail(dot)com> writes:
> On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> This seems pretty bizarre. What's the use case? Why would it not
>> be better to build the behavior out of other spare parts, along the
>> lines of COALESCE or perhaps
>> \if not defined(x)

> In light of the backticks variable expansion thread, I'm reviving this
> thread in the hopes that a defined()-ish psql function can make it into v10.
> It's something that cannot be solved with a query and \gset, so adding it
> to psql boolean expressions is the only option I can see.

I'm fairly hesitant to add stuff in advance of having a fairly clear
sketch of the boolean expression language we want. I don't mind
implementing such a language piece-by-piece, but if we just throw in
one or two features that seem like good ideas, I'm afraid we'll be
painting ourselves into a corner.

The only thing that seems locked down so far is that "a single argument
is a simple boolean value". If we were hot to support expr-style
comparison behavior, we could define cases with exactly three arguments
as being "\if value operator value". But I'm afraid that that would
cause problems because there would be other desirable behaviors (like
"\if not defined varname") that would also involve three arguments,
creating ambiguity.

I'm inclined to suggest that we should require all extensions beyond the
boolean-literal case to be set up as a keyword followed by appropriate
argument(s); that seems like it's enough to prevent syntax conflicts from
future additions. So you could imagine

\if defined varname
\if sql boolean expression to send to server
\if compare value operator value

It would be easy to allow "not" in front of any one of these, but
it's less clear how to do AND or OR combinations. You can always
fake AND with nested \if's, but OR is a bit more of a problem.
Maybe we don't need it.

Other ideas about how to design this?

regards, tom lane