On Sat, Dec 19, 2015 at 6:56 AM, Fabien COELHO <coe...@cri.ensmp.fr> wrote:
>> It was definitely useful to debug the double/int type stuff within
>> expressions when writing a non trivial pgbench script. It is probably less
>> interesting if there are only integers.
> 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? If all allocations within a variable are unconditionally
integers, why is it useful to make the cast function double()
user-visible? 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. I
am just doubting that it is actually necessary to make that visible at
user-level if they have no direct use..

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to