Re: Ryu floating point output patch - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: Ryu floating point output patch
Date
Msg-id 874lagotif.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Ryu floating point output patch  (Andrew Gierth <andrew@tao11.riddles.org.uk>)
Responses Re: Ryu floating point output patch
Re: Ryu floating point output patch
Re: Ryu floating point output patch
List pgsql-hackers
Rebased this patch onto current master. No functional changes; just
fixed up the copyright dates and a couple of stray missing UINT64CONSTs.

Regression tests still fail because how to fix them depends on the
issues below. Likewise docs are not changed yet for the same reason.

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?

  (this would likely mean adding a new GUC, rather than basing
  everything off extra_float_digits as the patch does now)

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

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

-- 
Andrew (irc:RhodiumToad)


Attachment

pgsql-hackers by date:

Previous
From: "Yuzuko Hosoya"
Date:
Subject: RE: Improve selectivity estimate for range queries
Next
From: Donald Dong
Date:
Subject: How does the planner determine plan_rows ?