Re: Ryu floating point output patch

Hi,

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.

Same.

> 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
here?

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

Greetings,

Andres Freund