Re: Variable substitution in psql backtick expansion

2017-04-10 13:07 GMT+02:00 Greg Stark <stark(at)mit(dot)edu>:

> On 2 April 2017 at 07:53, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:
> > Note that this is already available indirectly, as show in the
> > documentation.
> >
> > SELECT some-boolean-expression AS okay \gset
> > \if :okay
> > \echo boolean expression was true
> > \else
> > \echo boolean expression was false
> > \endif
>
>
> 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.
>

Totally agree.

> 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.
>
> I don't think taking a simple command line execution environment like
> psql and trying to embed a complete complex language parser in it is
> going to result in a sensible programming environment. Having a simple
> \if <single variable> is already pushing it. If someone wanted
> anything more complex I would strongly recommend switching to perl or
> python before trying to code up nesting arbitrary sql in nested
> expressions.
>

I think so some local expression evaluation could be - but it should not be
placed in \if statement

\expr issupported :VERSION_NUM >= 10000
\if :issuported

maybe \if can support the basic logic predicates NOT, OR, AND - but the
operands can be only evaluated variables

Regards

Pavel

> --
> greg
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>