Hi, On 2018-10-07 12:59:18 +0100, Andrew Gierth wrote: > >>>>> "Tom" == Tom Lane <t...@sss.pgh.pa.us> writes: > > Tom> Now, "shortest value that converts back exactly" is technically > Tom> cool, but I am not sure that it solves any real-world problem that > Tom> we have. > > Well, it seems to me that it is perfect for pg_dump. > > Also it's kind of a problem that our default float output is not > round-trip safe - people do keep wondering why they can select a row and > it'll show a certain value, but then doing WHERE col = 'xxx' on that > value does not find the row. Yes, testing equality of floats is bad, but > there's no reason to put in extra landmines.
+1 > Tom> I'm also worried that introducing it would result in complaints like > Tom> > https://www.postgresql.org/message-id/CANaXbVjw3Y8VmapWuZahtcRhpE61hsSUcjquip3HuXeuN8y4sg%40mail.gmail.com > > Frankly for a >20x performance improvement in float8out I don't think > that's an especially big deal. +1. There's plenty complaints where we just say "sorry that it bothers you, but these larger concerns made us that way". > I do not see any obvious way to use this code to generate the same > output in the final digits that we currently do (in the sense of > overly-exact values like outputting 1.89999999999999991 for 1.9 when > extra_float_digits=3). But, why would that be required? Just to placate people wanting exactly the same output as before? I don't quite get how that'd be a useful requirement. Obviously we *do* need to support outputting non-exponent style output where appropriate, but that should mostly be different massaging of d2d()'s output, instead of calling to_chars() as the ryu upstream code does. ISTM we also need to support *reducing* the precision (for the case where people intentionally reduce extra_float_digits), but that similarly should be a SMOP, right?- - Andres
