Re: [HACKERS] Variable substitution in psql backtick expansion
От | Fabien COELHO |
---|---|
Тема | Re: [HACKERS] Variable substitution in psql backtick expansion |
Дата | |
Msg-id | alpine.DEB.2.20.1704120828160.9028@lancre обсуждение исходный текст |
Ответ на | Re: [HACKERS] Variable substitution in psql backtick expansion (Corey Huinker <corey.huinker@gmail.com>) |
Ответы |
Re: [HACKERS] Variable substitution in psql backtick expansion
Re: [HACKERS] Variable substitution in psql backtick expansion |
Список | 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 по дате отправления: