Re: NaN/Inf fix for ECPG
От | Tom Lane |
---|---|
Тема | Re: NaN/Inf fix for ECPG |
Дата | |
Msg-id | 26148.1267289851@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: NaN/Inf fix for ECPG (Rémi Zara <remi_zara@mac.com>) |
Ответы |
Re: NaN/Inf fix for ECPG
|
Список | pgsql-hackers |
Rémi Zara <remi_zara@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? BTW, what about the float4 case, 'nan'::numeric::float4 ? > 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. regards, tom lane
В списке pgsql-hackers по дате отправления: