From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Matt Pulver <mpulver(at)unitytechgroup(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Infinity vs Error for division by zero |
Date: | 2019-03-01 18:04:38 |
Message-ID: | 20190301180438.4q5a3xung2ndwpea@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-03-01 12:46:55 -0500, Matt Pulver wrote:
> PostgreSQL FLOAT appears to support +/-Infinity and NaN per the IEEE 754
> standard, with expressions such as CAST('NaN' AS FLOAT) and CAST('Infinity'
> AS FLOAT) and even supports ordering columns of floats that contain NaN.
>
> However the query "SELECT 1.0/0.0;" produces an exception:
>
> ERROR: division by zero
>
>
> Question: If Infinity and NaN are supported, then why throw an exception
> here, instead of returning Infinity? Is it purely for historical reasons,
> or if it could all be done again, would an exception still be preferred?
>
> For purely integer arithmetic, I can see how an exception would make sense.
> However for FLOAT, I would expect/prefer Infinity to be returned.
It'd be good for performance reasons to not have to check for that, and
for under/overflow. But the historical behaviour has quite some weight,
and there's some language in the standard that can legitimate be
interpreted that both conditions need to be signalled, if I recall
correctly.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2019-03-01 18:15:21 | Re: Refactoring the checkpointer's fsync request queue |
Previous Message | David G. Johnston | 2019-03-01 18:04:04 | Re: Infinity vs Error for division by zero |