Re: Variable substitution in psql backtick expansion

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Variable substitution in psql backtick expansion
Date: 2017-04-11 23:42:07
Message-ID: alpine.DEB.2.20.1704120828160.9028@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2017-04-11 23:55:51 Re: error handling in RegisterBackgroundWorker
Previous Message Dmitry Ivanov 2017-04-11 21:59:16 Re: Possible problem in Custom Scan API