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 CAFj8pRC=inphd=S16KjGqq+RcmR+YBMAts0JxTDg8VGp8itRzg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Variable substitution in psql backtick expansion  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers


2017-04-11 9:07 GMT+02:00 Fabien COELHO <coelho@cri.ensmp.fr>:

I think so implementation of simple expression evaluation should not be
hard

Indeed it is not hard, it is rather a matter of deciding what it should do, and the syntax to do it.

- really just - we can expect so any variable will be replaced by
const in expression

Num (<|>|=|<=|>=) Num

<> and != would seem handy as well.

sorry - I forgot

 


Text (<|>|=|<=|>=) Text

What would be the use case for handling TEXT?

not Bool, Bool (or|and) Bool

Aka logical expressions.

and special operator "defined"

I'm still not buying this suggestion at all because it does not look like SQL and I think that client-side expressions should be a simple subset of SQL expressions, which a "defined" operators is definitely not.

The "defined" tests is not coming from SQL universe. It is coming from scripting systems - In plain SQL I can use IS NULL. When I check any not existing variable in plpgsql I expect syntax error. So SQL doesn't know any similar to "defined" and it is ok. Currently In psql it is similar. When I use undefined psql variable I got syntax error. When I expect so some content of command line will come from command line or (possible) from some interactive action I would to handle this situation to by my script more user friendly - and I can write more user friendly error messages or I can react on it - enforce user input.

I cannot do test on client side test on NULL - currently psql variables doesn't support it - and I am think so it is not what I want - I am interesting about some meta information from outside. 

else

I need to check if I can use some psql variable. I have to do on client side. In some languages is usual term defined - some other using some special syntax or special environments.

The my proposal "defined variablename" should be simple on implementation, but should not be one. It is just proposal.

The tests:

variable is defined, variable is null, ... is acceptable for me too - although I have small problem with NULL, because NULL can got from server - more psql variables doesn't support NULL, and support can enforce incompatible change.



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.

Sure.

--
Fabien.

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: [HACKERS] Range Merge Join v1
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] max_sync_workers_per_subscription is missing in postgresql.conf