On Thu, Nov 5, 2015 at 3:33 PM, Fabien COELHO <coe...@cri.ensmp.fr> wrote:
> For the '+' overload operator with conversions there are 4 cases (2
> arguments ** 2 types) to handle. For all 5 binary operators (+ - * / %).
> that makes 20 cases to handle. Then for every function, you have to deal
> with type conversion as well, each function times number of arguments **
> number of types. That is 2 cases for abs, 4 cases for random, 8 cases for
> each random_exp*, 8 for random_gaus*, and so on. Some thinking would be
> required for n-ary functions (min & max).
>
> Basically, it can be done, no technical issue, it is just a matter of
> writing a *lot* of repetitive code, hundreds of lines of them. As I think it
> does not bring any value for pgbench purpose, I used the other approach
> which reduces the code size by avoiding the combinatorial "cross-type"
> conversions.
Those can be avoided in other ways. For example:
if (x->type == PGBT_INTEGER && y->type == PGBT_INTEGER)
{
result->type = PGBT_INTEGER;
result->u.ival = x->u.ival + y->u.ival;
}
else
{
result->type = PGBT_DOUBLE;
result->u.ival = coerceToDouble(x) + coerceToDouble(y);
}
coerceToDouble can re-used for every arithmetic operator and can throw
an error if the input type is not coercible. Yet, we still return an
exact integer answer when possible.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
