Re: extend pgbench expressions with functions

Hello Robert,

> For example, I just realized that this patch allows values to be
> either a double or an integer and extends the operators to handle
> double values.  But variables can still only be integers.

Indeed.

> [...] at least flatten everything to string rather than integer so that 
> you can store the value without loss of precision - just with loss of 
> type-safety.  I think designing this in this way is quite short-sighted.

Note that I'm not responsible for this design, which is preexisting. 
Extending variables to be able to store doubles could also be done in 
another patch.

> I don't think variables should be explicitly typed but they should be 
> able to store a value of any type that expression evaluation can 
> generate.

Doubles are not really needed that much, it is just to provide something 
to random_* functions parameter, otherwise it is useless as far as pgbench 
is really concerned.

> Also, as I said back in November, there's really two completely
> separate enhancements in here.  One of them is to support a new data
> type (doubles) and the other is to support functions.

Yep. The first part is precisely the patch I initially submitted 5 CF ago.

Then I'm asked to put more things in it to show that it can indeed handle 
another type. Then I'm told "you should not have done that". What can I 
say?

> Those should really be separate patches.

They could.

> [...] I find implementing operators as functions in disguise not to be 
> one of PostgreSQL's most awesome design decisions, and here we are 
> copying that into pgbench for, well, no benefit that I can see, really.

Well, I did that initially, then I was asked to implements operators as 
functions. It probably saves some lines, so it is not too bad, even if the 
benefit is limited.

> Maybe it's a good idea and maybe it's a bad idea, but how do we know?

This is just pgbench, a tool for testing performance by running dummy 
transactions, not a production thing, so I think that it really does not 
matter. There is no user visible changes wrt operators.

> [...] If neither of you are willing to split this patch, I'm not willing 
> to commit it.

If I'm reading you correctly, you would consider committing it:
 - if the function & double stuff are separated ?
 - for the double part, if variables can be double ?

-- 
Fabien.