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