| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Wrong results from in_range() tests with infinite offset |
| Date: | 2020-07-21 02:06:32 |
| Message-ID: | 794665.1595297192@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> The other three cases where we'd hit NaNs are likewise symmetric with
> non-NaN cases that'd return TRUE. Hence, I'm forced to the conclusion
> that you've got it right above. I might write the code a little
> differently, but const-TRUE-for-NaN-cases seems like the right behavior.
> So I withdraw my objection to defining it this way. Unless somebody
> else weighs in, I'll commit it like that in a day or two.
Pushed, but I chickened out of back-patching. The improvement in what
happens for finite comparison values seems somewhat counterbalanced by
the possibility that someone might not like the definition we arrived
at for infinities. So, it's not quite an open-and-shut bug fix, so
I just put it in HEAD (for now anyway).
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | k.jamison@fujitsu.com | 2020-07-21 02:36:14 | RE: Parallel Seq Scan vs kernel read ahead |
| Previous Message | Tom Lane | 2020-07-20 23:46:24 | Re: NaN divided by zero should yield NaN |