Re: [HACKERS] PSQL commands: \quit_if, \quit_unless
| От | Pavel Stehule |
|---|---|
| Тема | Re: [HACKERS] PSQL commands: \quit_if, \quit_unless |
| Дата | |
| Msg-id | CAFj8pRBF-z8jUPXu_2JuCaXAzVeWi0m9O1muMqoky5yzmYyPmA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] PSQL commands: \quit_if, \quit_unless ("David G. Johnston" <david.g.johnston@gmail.com>) |
| Список | pgsql-hackers |
2016-12-16 18:33 GMT+01:00 David G. Johnston <david.g.johnston@gmail.com>:
2016-12-16 18:21 GMT+01:00 David G. Johnston <david.g.johnston@gmail.com>: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_notNot following the thread that closely and the section Robert quoted didn't include "\if_not" as a syntax option. I figured the idea was to limit the number of backslash commands and leave the power in the expression evaluation.
without a expression you can store a negation to variable
I can imagine simple functional only expressions evaluated on client side.
\if not(table_exists('table_name'))
full expressions are not easy implemented without bigger changes in psql parser design - and I don't see any reason why do some too complex there. I would not to replace bash, perl, python or lua.
David J.
В списке pgsql-hackers по дате отправления: