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.
