Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] [BUGS] BUG #2846: inconsistent and

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>, Roman Kononov <kononov195-pgsql(at)yahoo(dot)com>
Subject: Re: [HACKERS] [BUGS] BUG #2846: inconsistent and
Date: 2006-12-29 15:52:24
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)us> 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?
> 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.
> 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 €0.02

greetings, Florian Pflug

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-12-29 15:58:37
Subject: Re: TODO: GNU TLS
Previous:From: Stephen FrostDate: 2006-12-29 15:50:35
Subject: Re: TODO: GNU TLS

pgsql-patches by date

Next:From: Andrew DunstanDate: 2006-12-29 16:02:53
Subject: Re: Recent SIGSEGV failures in buildfarm HEAD
Previous:From: Brian HurtDate: 2006-12-29 15:45:04
Subject: Re: [PATCHES] [BUGS] BUG #2846: inconsistent and

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group