Re: Bug / feature request for floating point to string conversion

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

In response to

Browse pgsql-hackers by date

  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