From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Frey <d(dot)frey(at)gmx(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bug / feature request for floating point to string conversion |
Date: | 2012-10-10 18:26:45 |
Message-ID: | 3028.1349893605@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Frey <d(dot)frey(at)gmx(dot)de> writes:
> INSERT INTO dummy VALUES ( '0X1P-1022' );
> this value itself is the problem. If I use pg_dump / pg_restore, the restore fails with:
> COPY failed for table "dummy": ERROR: "2.22507385850720138e-308" is out of range for type double precision
> This behavior might depend on the system's implementation of strtod(), I'm using Ubuntu 12.04.
That is definitely a bug in strtod, which you should report. If it
doesn't accept a value that sprintf output, something is broken at the
libc level.
> While the problem occurs when importing the data back, the root (IMHO) is, that I can not request floating point values (datatypes REAL and DOUBLE PRECISION) to be returned as strings with the hexadecimal notation (which would easily preserve all bits).
That's not much of a solution from our standpoint, because it assumes
that every platform has such a feature (and that they all agree on what
the hex notation means).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Boszormenyi Zoltan | 2012-10-10 18:36:07 | Re: [PATCH] Make pg_basebackup configure and start standby [Review] |
Previous Message | Tom Lane | 2012-10-10 17:57:31 | Re: Minor document updates |