Bonjour Michaël,

Hmm. It seems to me that this stuff needs to be more careful with the function handling? For example, all those cases fail but they directly pass down a variable that may not be defined, so shouldn't those results be undefined as well instead of failing:

\set g double(:{?no_such_variable})
\set g exp(:{?no_such_variable})
\set g greatest(:{?no_such_variable}, :{?no_such_variable})
\set g int(:{?no_such_variable})

I do not understand: All the above examples are type errors, as ":{?var}" is a boolean, that cannot be cast to double, be exponentiated etc. So failing just seems appropriate.

Maybe casting boolean to int should be allowed, though, as pg does it.

It seems to me that there could be a point in having the result of any
function to become undefined if using at least one undefined argument
(the point could be made as well that things like greatest just ignore
conditioned variables), so I was surprised to not see the logic more
linked with ENODE_VARIABLE.

Hmmm… :var (ENODE_VARIABLE) replaces de variable by its value, and it fails if the variable is not defined, which is the intention, hence the point of having the ability to test whether a variable exists, and its new expression node type.

It could replace it by NULL when not existing, but ISTM that a script can wish to distinguish NULL and undefined, and it departs from SQL which just fails on a undefined alias or column or whatever.

If someone wants to go back to having a self propagating NULL, they can simply

  \if :{?var}
  \set var NULL
  \endif

Or

  \set var CASE WHEN :{?var} THEN :var ELSE NULL END

to get it.

Having some special UNDEF value looks unattractive, as it would depart for SQL even further.

If your intention is to keep this behavior, it should at least be tested I guess.

My intention is to keep failing on type errors, but maybe I'm missing something of your point.

Please note that this patch will have to wait until v14 opens for business for more.

Sure. I put it in the July CF, and I do not expect to it to be processed on the first CF it appears in.

--
Fabien.

Reply via email to