Re: PSQL commands: \quit_if, \quit_unless

2016-12-16 18:21 GMT+01:00 David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>:

> On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
>
>> On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas <robertmhaas(at)gmail(dot)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.
>
>
>
>