From: | Daniel Frey <d(dot)frey(at)gmx(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Bug / feature request for floating point to string conversion |
Date: | 2012-10-10 20:22:25 |
Message-ID: | 493B53F4-7798-4D65-AE34-0B00BAFC9645@gmx.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 10.10.2012, at 20:26, Tom Lane wrote:
> 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.
Who guarantees that? While I would have hoped for strtod() to accept everything generated from sprintf() from a valid float/double, I don't see anyone giving you this guarantee. I'd be happy to be wrong about this, but until then, I think that pg_dump/pg_restore can not be guaranteed to work, right?
Regards, Daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-10-10 20:28:24 | Re: Move postgresql_fdw_validator into dblink |
Previous Message | Tomas Vondra | 2012-10-10 20:21:51 | change in LOCK behavior |