Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
