2016-12-16 18:21 GMT+01:00 David G. Johnston <david.g.johns...@gmail.com>:
> On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas <robertmh...@gmail.com> > wrote: > >> On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas <robertmh...@gmail.com> >> wrote: >> >> - possible incremental implemention steps on this path: >> >> >> >> (1) minimal condition and expression, compatible with >> >> a possible future full-blown expression syntax >> >> >> >> \if :variable >> >> \if not :variable -- maybe \if ! :variable >> > > We don't presently have a unary boolean operator named "!" so adding this > variant would create an inconsistency > If we allow some complex expressions there, then it should be a SQL expressions evaluated on server side. There are two variants - 1. simple client side expression - can be functional only, 2. complex server side expression. > >> So I think it would be reasonable for somebody to implement \if, >> \elseif, \endif first, with the argument having to be, precisely, a >> single variable and nothing else (not even a negator). Then a future >> patch could allow an expression there instead of a variable. I don't >> think that would be any harder to review than going all the way to #5 >> in one shot, and actually it might be simpler. > > > I worry about the case of disallowing negation in #1 and then not > getting to #5 (in the same version) where the expression "not(var)" becomes > possible. > > If the expected committed patch set includes #5 then this becomes a matter > for reviewer convenience so never mind. But if its at all possible for #5 > to be punted down the road incorporating the eventual "not var" and > "not(var)" syntax into #1 as a kind of shim would seem desirable. > why do you need special operator for negation? there is only one use case. It can be solved by \if_not > > David J. > > > >
