On Wed, Aug 24, 2011 at 11:45 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Euler Taveira de Oliveira <euler@timbira.com> writes:
>> Em 24-08-2011 11:27, Tom Lane escreveu:
>>> Hmm. I agree we need to avoid executing 0/0 here, but should we force
>>> the result to 0, or to NaN?
>
>> If it returns NaN on other platforms, let's be consistent.
>
> I kinda suspect that the NaN behavior was not designed but accidental.
> What I'm wondering is whether it's really the "right", sensible,
> behavior.
>
> On reflection I suspect it isn't --- it'd bollix sum() or avg()
> calculations over the function's results, for instance. But now
> I'm not sure zero is the right thing to put in, either.
It's not very sensible to sum() or avg() such values from different
tables, but if you did wish to do so it would be easy enough to shove
a CASE statement in there to filter out the NaN results.
On a blank slate, I might choose to do it differently, but considering
that we have numerous releases out in the field that return NaN, I
think we should stick with that rather than using this minor bug as an
excuse to change the answer on platforms where this isn't already
broken.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
