Re: floating point output

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Rob Sargent <robjsargent(at)gmail(dot)com>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: floating point output
Date: 2019-09-09 05:03:06
Message-ID: 3868.1568005386@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Rob Sargent <robjsargent(at)gmail(dot)com> writes:
> Below I show a floating point column from a recent query.

> Here's my guess at what's happening in the formatting:
> 1) scientific notation if smaller than 1.0e-04 (I’m not in the very-much-larger-than-one world)
> 2) 15 digits after the most signicant 0
> 3) remove trailing zeros

> I may be alone in this but I find the presentation messy and that's
> unusual in the PostgreSQL world.

In released versions of Postgres, float8out basically devolves to
sprintf with "%.15g" format, and the above is what POSIX says that
should do.

As of v12, we'll use the "Ryu" output algorithm, which adjusts
the number of displayed digits to ensure that the value will
re-load exactly by default. I'm afraid that will probably make
your complaint about variable numbers of digits worse not better.
It's unlikely anybody will entertain an argument to undo it,
though, because (a) Ryu is faster than the old code, and (b) it's
hard to argue against ensuring that output/input preserves values.

You might consider using type "numeric" if you find truncation
of low-order zeroes undesirable.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Luca Ferrari 2019-09-09 06:48:51 Re: PG11.2 - wal_level =minimal max_wal_senders = 0
Previous Message Rob Sargent 2019-09-09 04:16:55 Re: floating point output