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.1704120828160.9028@lancre
Whole thread Raw
In response to Re: [HACKERS] Variable substitution in psql backtick expansion  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: [HACKERS] Variable substitution in psql backtick expansion  ("Daniel Verite" <daniel@manitou-mail.org>)
Re: [HACKERS] Variable substitution in psql backtick expansion  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
>> 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.
>
> I have no strong opinion on how expressive expressions should be, but
> having a separate \expr (or \setexpr, etc) gives us a green field to
> develop them.

Yep.

One possible approach would be to reuse pgbench expression engine in order 
to avoid redevelopping yet another lexer & parser & evaluator. This would 
mean some abstraction work, but it looks like the simplest & most 
effective approach right now. Currently it supports an SQL-expression 
subset about int & float, and there is an ongoing submission to add 
booleans and a few functions. If this is done this way, this suggests that 
variable management should/could be merged as well, but there are some 
differences (psql variables are not typed, it relies on a list, there is a 
"namespace" thing I'm not sure I understood...).

Pavel also suggested some support for TEXT, although I would like to see a 
use case. That could be another extension to the engine.

A drawback is that pgbench needs more powerfull client-side expressions 
than psql, thus it adds some useless complexity to psql, but avoiding 
another engine seems desirable.

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Dmitry Ivanov
Date:
Subject: Re: [HACKERS] Possible problem in Custom Scan API
Next
From: "David G. Johnston"
Date:
Subject: Re: [HACKERS] error handling in RegisterBackgroundWorker