Re: [HACKERS] Undefined psql variables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [HACKERS] Undefined psql variables
Date
Msg-id CAFj8pRAq1LnQchM-wH+q2awNRZjYvjxEAf73PsJb2zYtr2Lj+w@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Undefined psql variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: [HACKERS] Undefined psql variables  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers


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

Hello Corey,

        \if defined varname
        \if sql boolean expression to send to server
        \if compare value operator value

I'm still thinking:-)

Independently of the my aethetical complaint against having a pretty
unusual keyword prefix syntax, how would you envision a \set assignment
variant? Would \if have a different expression syntax somehow?

Any further thoughts?

My current opinion:

 - I'm fine if \set stays as it is, i.e. no expression.

 - I agree that some client-side expressions are needed, along the
   semantics suggested by Tom, i.e. definition and comparisons.

 - I'm really against the prefix syntax suggested by Tom


I wish I could have an explanation about why the :?varname (or some other variant) syntax I suggested has a "namespace" issue.

The advantage that I see is that although it is obviously ugly, it is ugly in the continuity of the various :["'?]varname syntaxes already offered and it allows to get rid of "defined varname" which does not look like SQL. A second advantage is that with the "defined" proposal

I don't think so this argument is valid - \if doesn't look like SQL too.
 

   \if defined var1 and defined var2 or defined var3 and sqlrt() >= ..

Would probably never work work, as it cannot be embedded in another expression, while it would work with

   \if :?var1 and :?var2 or :?var3 and ...


I don't see any reason why first should not work and second should to work
 

Moreover, I would like the condition syntax to be basically SQL & psql variables, without explicit prefixes, with a transparent decision whether it is evaluated client side or server side.

As client-side expressions are pretty simple, ISTM that some regex could be used for this purpose, eg for integer and boolean comparisons:

 ^\s*\d+\s*(=|<>|!=|<|<=|>|>=)\s*\d+\s*$
 ^\s*(bool...)\s*(=|<>|!=)\s*(bool...)\s*$
 ^\s*(NOT\s*)?(bool...)\s*$

So that one could just write the expressions without having to tell where it is executed, eg

 \if :VERSION_NUM < 110000

Would lead to

 \if 100000 < 110000

Caught by the first regex, and evaluated with a few lines of code.

I have a different opinion - the condition expression should not be SQL necessary. This language is oriented on client side operations. What is benefit from server side expression?

Regards

Pavel
 


--
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: Heikki Linnakangas
Date:
Subject: Re: [HACKERS] Duplicate assignment in Unicode/convutils.pm
Next
From: Merlin Moncure
Date:
Subject: Re: [HACKERS] Performance issue with postgres9.6