While testing 7a622b273 I happened to notice this: \set x greatest(3, 2, 4.9) create table mytab (x numeric); insert into mytab values(:x);
results in this table: x ---------------------- 4.900000000000000355 (1 row) The reason for that is that the result of a "double" calculation is coerced to text like this: sprintf(res, "%.18e", result.u.dval); apparently on the theory that this will result in being able to convert it back to double with no loss of low-order bits. But of course the last two or three digits of such output are pretty much garbage to the naked eye. Then what gets interpolated as the variable value is something like '4.900000000000000355e+00'. I think this is a very poor decision; it's going to cause surprises and probably bug reports. Moreover, if we were testing this behavior in the buildfarm (which we are not, but only because the test coverage for pgbench is so shoddy), we would be seeing failures, because those low-order digits are going to be platform dependent. The only value of doing it like this would be if people chained multiple floating-point calculations in successive pgbench \set commands and needed full precision to be retained from one \set to the next ... but how likely is that? A minimum-change fix would be to print only DBL_DIG digits here. A better answer, perhaps, would be to store double-valued variables in double format to begin with, coercing to text only when and if the value is interpolated into a string. That's probably a bigger change than we want to be putting in right now, though I'm a bit tempted to go try it. Thoughts? BTW, just to add insult to injury, the debug() function prints double values with "%.f", which evidently had even less thought put into it. That one should definitely be %g with DBL_DIG precision. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers