Le 27 févr. 2010 à 17:57, Tom Lane a écrit : > =?iso-8859-1?Q?R=E9mi_Zara?= <remi_z...@mac.com> writes: >> Le 26 févr. 2010 à 17:11, Tom Lane a écrit : >>> Hmm. So what do you get from >>> SELECT 'nan'::numeric::float8; > >> regression=# select 'nan'::numeric::float8; >> float8 >> ---------- >> Infinity >> (1 row) > >> So it is indeed the same behavior. > > Yeah. So what it boils down to is that the platform has a NAN constant > but casting it to double produces the wrong thing. There's no doubt > that that's a bug in the floating-point support. You did say you'd > submitted it to the NetBSD folk right? >
I submitted it. > BTW, what about the float4 case, 'nan'::numeric::float4 ? That works OK. > >> Maybe that should be added to the regression tests. > > Perhaps. A lot of this stuff was never stress-tested in the past > because when it was put in, it was a crap shoot whether NaN (or Inf) > really worked on most platforms. Our attitude was "if it works for you, > great, but we're not going to sweat about it if it doesn't". I'm not > sure whether full IEEE float support has gotten sufficiently universal > to justify expecting more. I guess we could try it and see how many > other buildfarm members fail. > >> So what's the best way to workaround the bug in NetBSD/mips ? > > I don't think it's our bug to fix. > It would mean retiring pika until/if the bug is fixed... :-( Regards, Rémi Zara -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
