NaN/Inf fix for ECPG
in [PgSql]
|
Prev: pgsql: Clean up package namespace use and use ofSafe in plperl.
Next: ToDo: plpgsql plugin for query and expression verification
From: Tom Lane on 26 Feb 2010 11:14 Michael Meskes <meskes(a)postgresql.org> writes: > On Fri, Feb 26, 2010 at 12:12:10PM +0100, Boszormenyi Zoltan wrote: >> Michael, can we try to install the first two patches? > If I understood the rest of the thread correctly this is not needed anymore, > right? I think it would be a good idea, just to have all that code using identical #includes. R�mi's problem may be a platform bug rather than something we can fix ourselves, but I think that making sure that ecpg uses the exact same coding that's been proven in the backend will forestall problems on other platforms. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: =?iso-8859-1?Q?R=E9mi_Zara?= on 27 Feb 2010 08:40 Le 26 févr. 2010 à 17:11, Tom Lane a écrit : > =?iso-8859-1?Q?R=E9mi_Zara?= <remi_zara(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 27 Feb 2010 15:50 =?iso-8859-1?Q?R=E9mi_Zara?= <remi_zara(a)mac.com> writes: > Le 27 f�vr. 2010 � 17:57, Tom Lane a �crit : >> I don't think it's our bug to fix. > It would mean retiring pika until/if the bug is fixed... :-( Grumble ... well, I suppose we've put in worse platform-specific hacks elsewhere. At least this is pretty localized. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Michael Meskes on 27 Feb 2010 16:56
On Fri, Feb 26, 2010 at 11:14:01AM -0500, Tom Lane wrote: > I think it would be a good idea, just to have all that code using > identical #includes. R�mi's problem may be a platform bug rather Sounds reasonable, done. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber meskes(a)jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |