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.