Re: Variable substitution in psql backtick expansion - Mailing list pgsql-hackers

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.