Re: [HACKERS] pow support for pgbench

>> 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.