From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: unsafe floats |
Date: | 2004-03-10 22:36:35 |
Message-ID: | 87ad2os51o.fsf@mailbox.samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Nowadays, IEEE float math is nearly universal, and we would be
> offering better functionality if we allowed access to Infinity and
> Nan by default.
This is faulty reasoning: we *do* allow NaN by default (although
you're correct that we reject Infinity in float8 input, but it seems
not by design).
> So I'd vote for ripping out the range check, or at least reversing
> the default state of UNSAFE_FLOATS.
This would surely be wrong. Defining UNSAFE_FLOATS will make
float4in() not check that its input fits into a 'float', rather than a
'double'.
> We might end up with two sets of regression expected files, one for
> machines that do not support NaN, but that seems acceptable to me.
Are there any modern machines that actually do not support NAN? There
are various places in the code that do
#ifndef NAN
#define NAN (0.0/0.0)
#endif
... and this hasn't caused any problems that I'm aware of.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-03-10 22:36:51 | Re: selective statement logging |
Previous Message | Neil Conway | 2004-03-10 22:21:14 | Re: unsafe floats |