Re: [HACKERS] Variable substitution in psql backtick expansion

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [HACKERS] Variable substitution in psql backtick expansion
Дата
Msg-id alpine.DEB.2.20.1704111459140.29476@lancre
обсуждение исходный текст
Ответ на Re: [HACKERS] Variable substitution in psql backtick expansion  (Greg Stark <stark@mit.edu>)
Ответы Re: [HACKERS] Variable substitution in psql backtick expansion
Список pgsql-hackers
Hello Greg,

>>   SELECT some-boolean-expression AS okay \gset
>>   \if :okay
>
> Am I the only one who thinks that even if \if got the ability to
> evaluate arbitrary SQL queries I would probably still always write
> things as above?

> I think putting arbitrary SQL expressions (let alone queries) would make 
> scripts just a total mess and impossible for humans to parse.

No. Pavel does not like them. Tom wants them to be eventually possible... 
However, fine with me if it is decided that there will never be 
server-side expressions after \if. A good thing is that it potentially 
simplifies minimal \if client-side expressions.

> Whereas storing the results in psql variables and then using those 
> variables in \if makes even fairly complex queries and nested \if 
> structures straightforward. It would also make it far clearer in what 
> order the queries will be evaluated and under which set of conditions.

Hmmm. I'm not sure I get it. The penalty I see is that it adds a 
dummy variable which must be given a sensible name, and for very short 
expressions this is not a win. But this is a minor point.

-- 
Fabien.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] contrib/bloom wal-check not run by default
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] recent deadlock regression test failures