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