Re: [HACKERS] Variable substitution in psql backtick expansion
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] Variable substitution in psql backtick expansion |
Дата | |
Msg-id | alpine.DEB.2.20.1704111546170.29476@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] Variable substitution in psql backtick expansion (Pavel Stehule <pavel.stehule@gmail.com>) |
Ответы |
Re: [HACKERS] Variable substitution in psql backtick expansion
Re: [HACKERS] Variable substitution in psql backtick expansion |
Список | pgsql-hackers |
Hello Pavel, > I think so some local expression evaluation could be - but it should not be > placed in \if statement Why? > \expr issupported :VERSION_NUM >= 10000 Hmmm. Although I do not buy this, it could work as a replacement for \set which it seems cannot be upgraded because some people may rely on it to just store whatever comes after it in a variable. Maybe \setexpr or \set_expr because it is setting a variable and there is already a \set. > \if :issuported > > maybe \if can support the basic logic predicates NOT, OR, AND - ISTM that "NOT" is a minimal requirement, and the easy one. Note that OR & AND imply a syntax tree, handling parentheses, not in the same league. > but the operands can be only evaluated variables. Why? If your idea was to be followed, it seems to suggest two parsers with different constraints, one for the suggested "\expr" and one for the existing "\if". I think that if there is a client expression lexer/parser/executor, there would be just one of them for one syntax. Two is one too many. -- Fabien.
В списке pgsql-hackers по дате отправления: