On Fri, Jun 10, 2011 at 17:20, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I put this right about on par with the occasional suggestions that we
> implement our own filesystem. It's not our core competency and in the
> end there is no value-add. If you need to work with denormals, find
> a platform that supports them better.
Sorry if I wasn't clear on this. I don't care whether PostgreSQL
supports denormal float calculations or not. I know PostgreSQL doesn't
offer IEEE 754 floating point semantics.
I am worried that legitimate calculations can bring the database into
a state where a backup succeeds, but is no longer restorable.
Obviously making reliable backups is the job of a database.
Case in point:
% psql -c 'create table foo as select 0.25e-307::float8/2 as val'
SELECT 1
% pg_dump -t foo > foo.sql
% psql -c 'drop table foo'
% psql < foo.sql
...
ERROR: "1.24999999999999964e-308" is out of range for type double precision
CONTEXT: COPY foo, line 1, column val: "1.24999999999999964e-308"
I see four ways to make this work:
1. Clamp denormal numbers to 0.0 when stored into a table.
2. Throw an error when denormal numbers are stored into a table.
3. Use the FTZ (flush-to-zero) FPU mode so denormal values never
appear. I'm not sure whether this is available on all target
architectures.
4. Change the float4in and float8in functions to accept denormal float
literals. This has a nice side-effect of enabling full IEEE 754
floating point range.
Regards,
Marti