Re: Ryu floating point output patch

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Chapman Flack <chap(at)anastigmatix(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Ryu floating point output patch
Date: 2019-01-11 18:30:15
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2019-01-11 12:55:54 -0500, Robert Haas wrote:
> About as much as I can say is that if you commit this patch, and as a
> result, a dump-and-restore from v11 to v12 causes a change in the bits
> on disk that would not have occurred without this patch, that's very
> bad. What ramifications there will be if the output changes in ways
> that don't affect the bits that get written to the platter -- I don't
> know.

Are you trying to highlight the potential dangers of this patch, or are
you seeing a concrete risk of that in the discussion? Both ryu's and the
current output (as used by pg_dump, with extra_float_digits = 3) ought
to be roundtrip safe. There's possibly some chance for differences in
insignificant bits, but that ought to be pretty much it?

The current discussion would probably change the data that's stored on disk
between ryu/non-ryu for queries like
CREATE TABLE AS SELECT floatcol::text::float FROM ...
CREATE TABLE AS SELECT floatcol::text FROM ...

when not specifyiung extra_float_digits = 3, but the ryu case would be
more precise, so that ought to be good?


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-01-11 18:33:25 Re: Policy on cross-posting to multiple lists
Previous Message Robert Haas 2019-01-11 18:27:43 Re: New vacuum option to do only freezing