>> The fact that the return type is not consistently of one type bothers
>> me. I'm not sure pgbench's expression language is a good place to
>> runtime polymorphism -- SQL doesn't work that way.
>
> Sure.
>
> Pg has a NUMERIC adaptative precision version, which is cheating, because it
> can return kind of an "int" or a "float", depending on whether there are
> digits after the decimal point or not.
>
> Pgbench does not have support for NUMERIC, just INT & DOUBLE, so the current
> version is an approximation of that.
>
> Now it is always possible to just do DOUBLE version, but this won't match SQL
> behavior either.
Another point I forgot: pgbench functions and operators are notably
interesting to generate/transform keys in tables, which are usually
integers, so having int functions when possible/appropriate is desirable,
which explain why I pushed for having an int version for POW.
Also, pgbench does not have a static typing model because variable types
are not declared "\set i ...", so the type is somehow "guessed" based on
the string values, although if in doubt it is always possible to convert
(with "int" & "double" functions).
So for me the philosophy is to have expression match SQL behavior when
possible, as closely as possible, but it is not an exact match.
--
Fabien.
