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