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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
