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
> > 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 (firstname.lastname@example.org)
> To make changes to your subscription: