Re: Variable substitution in psql backtick expansion

2017-04-11 8:17 GMT+02:00 Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>:

>
> 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.

I think so implementation of simple expression evaluation should not be
hard - really just - we can expect so any variable will be replaced by
const in expression

Num (<|>|=|<=|>=) Num
Text (<|>|=|<=|>=) Text
not Bool
Bool (or|and) Bool

and special operator "defined"

It think so it is all what is necessary to calculate on client side (maybe
text operations are not necessary)

It can be good enough to write

\if not defined somevar
\quit "var is not defined"
\else
\if :somevar > 10000 and SERVER_NUM >= 100000
...
\end
\end

>
>
> 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.

I know so it is not ideal - but the language with commands "\if", "\else"
... is not ideal language.

I am very happy so Corey did this work, but I have not and I had not idea
of using psql scripting like full functionality language - you know it well
- the hard barrier is interactivity of psql.

Sometimes I have a idea start new client - and maybe the generic usql
client written in go can be good possibility. This client can have
integrated some language like lua, that can be used for some client side
scripting, maybe for tab complete, ... But it is in my dream area :) - back
to ground :).

>
>
> --
> Fabien.
>
>
>
> --
> 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
>