Re: [HACKERS] PSQL commands: \quit_if, \quit_unless

Поиск
Список
Период
Сортировка
От Pavel Stehule
Тема Re: [HACKERS] PSQL commands: \quit_if, \quit_unless
Дата
Msg-id CAFj8pRCgTUzk+qV3-LPHTnJFC+NSJtz404dBtUPWRx+aZPBpMA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] PSQL commands: \quit_if, \quit_unless  ("David G. Johnston" <david.g.johnston@gmail.com>)
Ответы Re: [HACKERS] PSQL commands: \quit_if, \quit_unless  ("David G. Johnston" <david.g.johnston@gmail.com>)
Re: [HACKERS] PSQL commands: \quit_if, \quit_unless  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers


2016-12-16 18:21 GMT+01:00 David G. Johnston <david.g.johnston@gmail.com>:
On Fri, Dec 16, 2016 at 9:55 AM, Robert Haas <robertmhaas@gmail.com> wrote:
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

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.


 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: [HACKERS] invalid number of sync standbys in synchronous_standby_names
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Creating a DSA area to provide work space for parallelexecution