Re: [HACKERS] pow support for pgbench

Hello Tom,

>>> 1. A patch that adds an integer version of pow() but not a double version
>>> 2. A patch that adds a double version of pow() but not an integer version
>>> 3. A patch that adds both an integer version of pow() and a double
>>> version of pow(), with the two versions having different names
>
>> It seems to me that 1 and 2 have value on their own for the workloads
>> tried to be emulated, so what you are suggesting in 3 looks good to
>> me. Now why are two different function names necessary?
>
> ISTM one key issue here is whether pgbench's expression language is
> meant to model SQL (where we have function overloading) or C (where
> there is no overloading).  I don't think we've really settled on a
> fixed policy on that, but maybe now is the time.

Function overloading is implemented for ABS (as noted by Michaël), but 
also LEAST and GREATEST. Typing is dynamic, based on guessing (think 
"pgbench -D i=1 -D f=1.0") . These decisions have already been taken, they 
were reasonable, the behavior is consistent and useful.

I do not see the point of going backward and breaking compatibility.

The idea is to model after SQL (eg also I've been asked to do that for the 
operators & functions extensions, lost in the CF queue), when possible.
When possible is not always.

> If we do think that function overloading is OK, there remains the
> question of when the typing is resolved.

Dynamic guessing is the only pragmatic option with pgbench.

> I think Robert is objecting to resolving at runtime, and I tend to agree 
> that that's something we'd regret in the long run.

Too late. I do not think that we would come to regret it. I'm rather 
regretting that pgbench capabilities are improving so slowly.

> It doesn't match either SQL or C.

Sure. A dynamically typed language cannot match a statically typed one. I 
do not see this as a significant issue for writing benchmarking scripts.


Now, about POW:

As for approximating NUMERIC, there is a first difficulty, as the type can 
either be approximated as an INT or DOUBLE. Ah ah.

Also, POW raises another difficulty, which is that depending on the sign 
of the second argument the result is more INT or more DOUBLE. Fun.

So even if we do separate functions (IPOW & DPOW, or POW & DPOW), the 
result cannot be typed statically.

Note that type can be enforced if necessary thanks to int() and double() 
functions, which is enough of a work around for pgbench simple purpose.

In this context, ISTM that Raul patch is a reasonable, even if imperfect, 
compromise.


I can understand that this compromise does not suit Robert. Too bad, 
because both POW versions (int & double) have a reasonable use case for 
writing benchmarks. Using two names does not resolve the typing issue 
anyway. None of the 3 options offered by Robert are really satisfactory, 
and the compromise is also rejected.

So basically do whatever you want with the patch (accept, reject, 1, 2, 
3). Only "Returned with feedback" with the feedback being "please 
implement a statically typed pgbench" does not seem like a useful option.

I can only say that these functions would be useful, so for me it is 
better in than out, but that is just my silly opinion.

-- 
Fabien.