Re: [HACKERS] Variable substitution in psql backtick expansion - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] Variable substitution in psql backtick expansion
Date
Msg-id alpine.DEB.2.20.1704111546170.29476@lancre
Whole thread Raw
In response to Re: [HACKERS] Variable substitution in psql backtick expansion  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: [HACKERS] Variable substitution in psql backtick expansion  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] Variable substitution in psql backtick expansion  (Corey Huinker <corey.huinker@gmail.com>)
List 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 by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange
Next
From: Pavel Stehule
Date:
Subject: Re: [HACKERS] Variable substitution in psql backtick expansion