| 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: | Whole Thread | Raw Message | 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)
| 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) |