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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
