Re: Ryu floating point output patch

From: Andres Freund <andres(at)anarazel(dot)de>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Ryu floating point output patch
Date: 2019-01-11 18:09:42
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


On 2019-01-11 02:40:25 +0000, Andrew Gierth wrote:
> Decisions that need to be made in order to proceed:
> 1. Should exact output become the default, or is it more important to
> preserve the historical output?
> I will argue very strongly that the default output should be exact.


> 2. How far do we need to go to support existing uses of
> extra_float_digits? For example, do we need a way for clients to
> request that they get the exact same output as previously for
> extra_float_digits=2 or 3, rather than just assuming that any
> round-trip-exact value will do?

I think it might be ok to say that any positive value will yield
round-trip-exact values, even if they're not precisely the same as the
ones before.

> 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.)

Hm. What's the argument to not just always use roundtrip-safe conversion

> 4. Can we allow declaration-after-statement please? That would allow
> keeping this code significantly closer to its upstream.

As I said on IRC: I'm personally on-board with changing this styilistic
requirement, but I also think that it'd be OK to just disable the
warning for the individual object files when they're imported (likely
using target specific makefile variable assignements) if we cannot get
agreement on the global policy change.


Andres Freund

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-01-11 18:19:34 Re: Early WIP/PoC for inlining CTEs
Previous Message Andres Freund 2019-01-11 18:04:51 Re: Making WAL receiver startup rely on GUC context for primary_conninfo and primary_slot_name