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.1704111459140.29476@lancre
Whole thread Raw
In response to Re: [HACKERS] Variable substitution in psql backtick expansion  (Greg Stark <stark@mit.edu>)
Responses Re: [HACKERS] Variable substitution in psql backtick expansion  (Pavel Stehule <pavel.stehule@gmail.com>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] contrib/bloom wal-check not run by default
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] recent deadlock regression test failures