| 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: | Whole Thread | Raw Message | 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 |