Re: Variable substitution in psql backtick expansion

Hello Pavel,

> The expression evaluation is interesting question, but there is a
> workaround - we can use \gset already.

Yes, that is a good point. It is a little bit inconvenient because it 
requires a dummy variable name each time for testing.

   SELECT whatever AS somename \gset
   \if :somename

But this is an already functional solution to use server-side expressions, 
so there is no hurry.

> What is more important, because there is not any workaround, is detection
> if some variable exists or not.
>
> So possibilities
>
> 1. \if defined varname

Yep, and as Tom pointed it should handle NOT as well.

My issue with this version is that Lane Tom convinced me some time ago 
that client side expressions should look like SQL expressions, so that 
everything in the script is somehow in the same language. I think that he 
made a good point.

However "defined varname" is definitely not an SQL expression, so I do not 
find that "intuitive", for a given subjective idea of intuitive.

Then there is the question of simple comparisons, which would also make 
sense client-side, eg simple things like:

   \if :VERSION_NUM >= 110000

Should not need to be executed on the server.

> 2. \ifdefined or \ifdef varname

I think that we want to avoid that if possible, but it is a cpp-like 
possibility. This approach does not allow to support comparisons.

> 3. \if :?varname

Tom suggested that there is a special namespace problem with this option. 
I did not understand what is the actual issue.

> I like first two, and I can live with @3 - although it is not intuitive

For me @3 is neither worth nor better than the already existing :'varname' 
and :"varname" hacks, it is consistent with them, so it is just an 
extension of the existing approach.

It seems easy to implement because the substitution would be handled by 
the lexer, so there is no need for anything special like looking at the 
first or second word, rewinding, whatever.

Basically I agree with everything Tom suggested (indeed, some client side 
definition & comparison tests are really needed), but not with the 
proposed prefix syntax because it does not look clean and SQL.

-- 
Fabien.