Re: [HACKERS] pow support for pgbench - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] pow support for pgbench
Date
Msg-id alpine.DEB.2.20.1712031007040.11574@lancre
Whole thread Raw
In response to Re: [HACKERS] pow support for pgbench  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
>> 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.


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: pg_dumpall -r -c try to drop user postgres
Next
From: Ashutosh Bapat
Date:
Subject: Re: [HACKERS] advanced partition matching algorithm forpartition-wise join