Re: Ryu floating point output patch - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Ryu floating point output patch
Date
Msg-id 87y37qmwee.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: Ryu floating point output patch  (Andres Freund <andres@anarazel.de>)
List 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)


pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: unnecessary creation of FSM files during bootstrap mode
Next
From: David Steele
Date:
Subject: Re: Checksum errors in pg_stat_database