Re: Variable substitution in psql backtick expansion

From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: 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 06:17:57
Message-ID: alpine.DEB.2.20.1704111459140.29476@lancre
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2017-04-11 06:25:26 Re: recent deadlock regression test failures
Previous Message Michael Paquier 2017-04-11 05:49:48 Re: contrib/bloom wal-check not run by default