Re: Ryu floating point output patch
Andrew Gierth <andrew@tao11.riddles.org.uk>
From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Date: 2019-01-12T02:53:14Z
Lists: pgsql-hackers
>>>>> "Andres" == Andres Freund <andres@anarazel.de> writes: >> 3. Do we need to do anything about how conversions from floats to >> numeric work? At present they _ignore_ extra_float_digits >> (presumably on immutability grounds) and convert using only DBL_DIG >> digits of precision. >> >> I have no very strong position on this but incline to keeping the >> existing behavior, though possibly it would be good to add functions >> to get the round-trip value and possibly even the true exact value. >> (It would be sort of nice if CAST(floatval AS numeric(400,18)) or >> similar could work as you'd expect, but currently we treat that as >> floatval::numeric::numeric(400,18) so the cast function doesn't know >> about the eventual typmod.) Andres> Hm. What's the argument to not just always use roundtrip-safe Andres> conversion here? Hmm. I was thinking that the fact that the existing conversion didn't respect extra_float_digits probably meant that people didn't care. But searching, I do find some complaints about it, though mostly they get brushed off with some variant of "you're doing it wrong". (Arguably any float to numeric conversion is a fairly dubious practice.) But I guess the case could be made for using the shortest-roundtrip-safe value here too. -- Andrew (irc:RhodiumToad)
Commits
-
Provide an extra-float-digits setting for pg_dump / pg_dumpall
- af25bc03e17e 12.0 landed
-
Change floating-point output format for improved performance.
- 02ddd499322a 12.0 landed
-
Use strtof() and not strtod() for float4 input.
- f397e08599a3 12.0 landed