Re: pow support for pgbench

Hi,

Indeed, this is quite strange...

I don't want to go too deep into it, but you get stuff like this:

Select pow(2.0, -3)::text = pow(2, -3)::text;
?column?
----------
f
(1 row)

- you can simplify the ipow function by removing handling of y<0 case,
> maybe add an assert to be sure to avoid it.

I agree, done.

- you should add more symmetry and simplify the evaluation:

Done too.

Add a test case to show what happens on NULL arguments, hopefully the
> result is NULL.

Done and it does.

Thanks again for the review.

On Mon, Nov 6, 2017 at 4:14 PM, Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> wrote:

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

--

*Raúl Marín Rodríguez *carto.com