Re: pgbench - test whether a variable exists

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.