2017-04-02 18:29 GMT+02:00 Tom Lane <t...@sss.pgh.pa.us>:

> Corey Huinker <corey.huin...@gmail.com> writes:
> > On Mon, Jan 23, 2017 at 12:53 PM, Tom Lane <t...@sss.pgh.pa.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



> 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@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to