On Mon, Apr 18, 2016 at 11:56:55PM -0400, Tom Lane wrote: > Noah Misch <n...@leadboat.com> writes: > > On Mon, Apr 18, 2016 at 10:22:59PM -0400, Tom Lane wrote: > >> We could alternatively set extra_float_digits to its max value and hope > >> that off-by-one-in-the-last-place values would get printed as something > >> visibly different from the exact result. I'm not sure I want to trust > >> that that works reliably; but maybe it would be worth printing the > >> result both ways, just to provide additional info when there's a failure. > > > We'd have an independent problem if extra_float_digits=3 prints the same > > digits for distinguishable float values, so I wouldn't mind relying on it > > not > > to do that. But can we expect the extra_float_digits=3 representation of > > those particular values to be the same for every implementation? > > Hm? The expected answer is exact (30, 45, or whatever) in each case. > If we get some residual low-order digits then it's a failure, so we don't > need to worry about whether it's the same failure everywhere.
Does something forbid snprintf implementations from printing '45'::float8 as 45.0000000000000001 under extra_float_digits=3? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers