Hi,
On 2018-10-07 12:59:18 +0100, Andrew Gierth wrote:
> >>>>> "Tom" == Tom Lane <tgl@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
