Re: Undefined psql variables

2017-04-02 18:29 GMT+02:00 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:

> 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
>

These possibilities looks well.

if defined varname is perfectly intuitive

Maybe it can be shorter - def, undef

\if def var, \if undef var

Regards

Pavel

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