Re: [HACKERS] PSQL commands: \quit_if, \quit_unless
| От | David G. Johnston |
|---|---|
| Тема | Re: [HACKERS] PSQL commands: \quit_if, \quit_unless |
| Дата | |
| Msg-id | CAKFQuwZJPtnbdW_rvmBXyjoUdLzoWuxZaMgrbyQqjcm1gxOgXw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] PSQL commands: \quit_if, \quit_unless (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [HACKERS] PSQL commands: \quit_if, \quit_unless
|
| Список | pgsql-hackers |
On Mon, Dec 5, 2016 at 12:32 PM, Robert Haas <robertmhaas@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
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.
David J.
В списке pgsql-hackers по дате отправления: