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

Hello Pavel,

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

Sure. I'm talking about the expressions after the "\if" which should be 
as close as SQL, I think. At least that is what Tom required about the 
expression syntax in pgbench, and I tend to agree that psql should avoid 
to mix in another language if possible.

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

Because of the mix of client-side and server-side stuff which needs to be 
interpreted. Let us consider:
  \if EXISTS (SELECT * FROM tbl WHERE id=3) AND defined foo

The "exists" is obviously executed server-side, but "defined foo" needs to 
be interpreted client-side, and it means that some parser client side 
would have been able to catch it in the middle of everything else. This 
example also illustrate my "does not look like SQL" point, as the first 
part is clearly SQL and the part after AND is not.

With the second approach, ... "AND :?foo", the ":?foo" reference would be 
substituted directly by psql lexer and replaced on the fly by the answer, 
resulting in "AND TRUE" or "AND FALSE" depending, then the whole result 
(from EXISTS to TRUE/FALSE) could be interpreted server side to get an 
answer.

Basically, catching :?varname seems easier/safer than catching "defined 
varname". I think that Tom's intent is that the defined expressions could 
not be mixed with SQL server side stuff, but I do not see why not, it is 
easy to imagine some use case where it would make sense.

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

Because I think it is legitimate to be able to write things like:
  \if NOT pg_extension_is_loaded('units')    \echo 'this application requires the great units extension'    \q  \endif
  \if (SELECT version FROM app_version) >= 2.0    \echo 'application already installed at 2.0'    \q  \endif

-- 
Fabien.