Re: [HACKERS] pow support for pgbench
| От | Fabien COELHO |
|---|---|
| Тема | Re: [HACKERS] pow support for pgbench |
| Дата | |
| Msg-id | alpine.DEB.2.20.1711061551450.5606@lancre обсуждение исходный текст |
| Ответ на | Re: [HACKERS] pow support for pgbench (Raúl Marín Rodríguez <rmrodriguez@carto.com>) |
| Ответы |
Re: [HACKERS] pow support for pgbench
|
| Список | pgsql-hackers |
Hello,
> Sorry for the confusion, I wasn't aware that SQL pow changed types
> depending on the input value.
Indeed, this is quite strange...
fabien=# SELECT i, POW(2, i) FROM generate_series(-2, 2) AS i; -2 | 0.25 -1 | 0.5 0 | 1 1 | 2 2 | 4
> I've modified the function to match more closely the behaviour of SQL,
> except that 0^(negative) returns 'double inf'. Do you think there is any
> value in raising an error instead?
fabien=# SELECT POW(0,-1); ERROR: zero raised to a negative power is undefined
Hmmmm... I'm fine with double inf, because exception in pgbench means the
end of the script, which is not desirable for benchmarking purposes.
I think that:
- you can simplify the ipow function by removing handling of y<0 case, maybe add an assert to be sure to avoid it.
- you should add more symmetry and simplify the evaluation:
if (int & int) { i1, i2 = ...; if (i2 >= 0) setIntValue(retval, ipow(i1, i2)); else
//conversion is done by C, no need to coerce again setDoubleValue(retval, pow(i1, i2)); } else { d1,
d2= ...; setDoubleValue(retval, pow(d1, d2)); }
Add a test case to show what happens on NULL arguments, hopefully the
result is NULL.
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: