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.
