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