Re: [HACKERS] Variable substitution in psql backtick expansion - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] Variable substitution in psql backtick expansion
Date
Msg-id CAFj8pRD=fEdBp1msMd8sO7uFVuBDtFKvDrw5RzwJ-GGGFKY-fQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Variable substitution in psql backtick expansion  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [HACKERS] Variable substitution in psql backtick expansion  (Pavel Stehule <pavel.stehule@gmail.com>)
Re: [HACKERS] Variable substitution in psql backtick expansion  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers


2017-04-11 8:17 GMT+02:00 Fabien COELHO <coelho@cri.ensmp.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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] recent deadlock regression test failures
Next
From: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange