On Sat, Dec 19, 2015 at 10:32 PM, Fabien COELHO <coe...@cri.ensmp.fr> wrote: > >>> 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.
I would honestly just remove this whole int() and double() business from what is available for the user, and mention on in the documentation clearly the return type and the types of the arguments of each function. And that's already what your patch is doing. >> 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. There is indeed a misunderstanding here: I meant from the start the removal of only the "double" function. It would be nice to keep as user-visible only things that have some meaning. >> 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. Well, if there were doubles as return results really allocated as doubles in variables having both would make sense. And honestly something like sqrt that returns an integer when allocated in a variable is really surprising.. And as you mentioned upthread there is no real meaning to have doubles variable types that can be allocated. (Moving this patch to next CF btw) -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
