Re: extend pgbench expressions with functions

>> After looking again at the code, I remembered why double are useful: there
>> are needed for random exponential & gaussian because the last parameter is a
>> double.
>>
>> I do not care about the sqrt, but double must be allowed to keep that, and
>> the randoms are definitely useful for a pgbench script. Now the patch may
>> just keep double constants, but it would look awkward, and the doc must
>> explain why 1.3 and 1+2 are okay, but not 1.3 + 2.4.
>>
>> So I'm less keen at removing double expressions, because it removes a key
>> feature. If it is a blocker I'll go for just the constant, but this looks to
>> me like a stupid compromise.
>
> Hm, say that you do that in a script: \set aid double(1.4) \set bid
> random_gaussian(1, 10, :aid) Then what is passed as third argument in
> random_gaussian is 1, and not 1.4, no?

Indeed.

Maybe pgbench should just generate an error when a variable is assigned a
double, so that the user must explicitly add an int() cast.

> If all allocations within a variable are unconditionally integers, why
> is it useful to make the cast function double() user-visible?

I'm not sure whether we are talking about the same thing:
- there a "double" type managed within expressions, but not variables
- there is a double() function, which takes an int and casts to double

I understood that you were suggesting to remove all "double" expressions,
but now it seems to be just about the double() function.

> Now, by looking at the code, I agree that you would need
> to keep things like DOUBLE and coerceToDouble(),
> PGBENCH_RANDOM_GAUSSIAN and its other friend are directly using it.

Yep.

> I am just doubting that it is actually necessary to make that visible at
> user-level if they have no direct use..

If there are both ints and doubles, then being able to cast make sense, so
I just put both functions without deeper thinking.

So I would suggest to generate an error when an double expression is
assigned to a variable, so as to avoid any surprise.

If both type are kept, I would like to keep the debug functions, which is
really just a debug tool to have a look at what is going within
expressions.

--
Fabien.