Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 8A2C39FA48A for ; Fri, 29 Dec 2006 11:52:41 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024) with ESMTP id 94727-01 for ; Fri, 29 Dec 2006 11:52:28 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from rivendell.solution-x.com (rivendell.solution-x.com [213.147.174.20]) by postgresql.org (Postfix) with ESMTP id 434269FA0B7 for ; Fri, 29 Dec 2006 11:52:35 -0400 (AST) Received: (qmail 27670 invoked from network); 29 Dec 2006 15:25:10 -0000 Received: from qmail by qscan (mail filter); 29 Dec 2006 15:25:10 +0000 Received: from unknown (HELO [10.105.0.26]) (fgp@[10.105.0.26]) (envelope-sender ) by rivendell.solution-x.com (qmail-ldap-1.03) with SMTP for ; 29 Dec 2006 15:25:10 -0000 Message-ID: <459539B8.5080904@phlo.org> Date: Fri, 29 Dec 2006 16:52:24 +0100 From: "Florian G. Pflug" User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Tom Lane CC: Bruce Momjian , pgsql-hackers@postgresql.org, PostgreSQL-patches , Roman Kononov Subject: Re: [HACKERS] [BUGS] BUG #2846: inconsistent and References: <200612291512.kBTFCVY02214@momjian.us> <2427.1167406410@sss.pgh.pa.us> In-Reply-To: <2427.1167406410@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200612/190 X-Sequence-Number: 21866 Tom Lane wrote: > Bruce Momjian writes: >> OK, are you saying that there is a signal we are ignoring for >> overflow/underflow, or that we should just silently overflow/underflow= >> and not throw an error? >=20 > Silent underflow is fine with me; it's the norm in most all float > implementations and won't surprise anyone. For overflow I'm OK with > either returning infinity or throwing an error --- but if an error, > it should only be about inf-out-with-non-inf-in, not comparisons to any= > artificial MAX/MIN values. >=20 > Anyone else have an opinion about this? If an underflow is not reported (And thus silently treated as zero), then= it'd make sense for me to deal with overflows in a similar way, and just return infinity. The most correct solution would IMHO be to provide a guc variable "strict_float_semantics" that defaults to "off", meaning that neather overflow nor underflow reports an error. If the variable was set to on, _both_ overflow and underflow would be reported. Just my =E2=82=AC0.02 greetings, Florian Pflug