Re: Zero-padding and zero-masking fixes for to_char(float)

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: Jeff Anton <antonpgsql(at)hesiod(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Zero-padding and zero-masking fixes for to_char(float)
Date: 2015-03-24 16:47:32
Message-ID: 87r3se7403.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

>>>>> "Jeff" == Jeff Anton <antonpgsql(at)hesiod(dot)org> writes:

Jeff> Postgresql seems to be using the first interpretation and
Jeff> reporting fewer digits. I've noticed this with pg_dump. That a
Jeff> dump and restore of floating point values does not produce the
Jeff> same floating point values. To me, that is inexcusable. Using
Jeff> the -Fc format, real values are preserved. I have a large
Jeff> database of security prices. I want accuracy above all.

-Fc doesn't do anything different with floats than text dumps do.

pg_dump (in all modes) uses the extra_float_digits setting to try and
get a value that restores exactly. There have been issues with this in
the past (the limit of extra_float_digits had to be raised from 2 to 3,
iirc), but if it's happening now then that should probably be considered
a bug.

--
Andrew (irc:RhodiumToad)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2015-03-24 18:25:25 Re: INT64_MIN and _MAX
Previous Message Jeff Anton 2015-03-24 16:26:10 Re: Zero-padding and zero-masking fixes for to_char(float)