Re: NaN/Inf fix for ECPG
От | Rémi Zara |
---|---|
Тема | Re: NaN/Inf fix for ECPG |
Дата | |
Msg-id | CAC0E717-9B5E-4261-AEC1-35C8BBA24E24@mac.com обсуждение исходный текст |
Ответ на | Re: NaN/Inf fix for ECPG (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: NaN/Inf fix for ECPG
|
Список | pgsql-hackers |
Le 26 févr. 2010 à 17:11, Tom Lane a écrit : > Rémi Zara <remi_zara@mac.com> writes: >> I've tried patch 1 and 2, but they do not work. The fact is that the code is not used in the backend, because strtod("NaN",endptr) works. (isnan(strtod("NaN", endptr)) is true). > > Hmm. So what do you get from > SELECT 'nan'::numeric::float8; > on that machine? That should exercise the backend's version of > get_float8_nan(). > regression=# select 'nan'::numeric::float8; float8 ----------Infinity (1 row) So it is indeed the same behavior. Maybe that should be added to the regression tests. So what's the best way to workaround the bug in NetBSD/mips ? (nan(""), (0.0/0.0), strtod("nan", null) ?) Regards, Rémi Zara
В списке pgsql-hackers по дате отправления: