| From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, laurenz(dot)albe(at)cybertec(dot)at, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Issue with point_ops and NaN |
| Date: | 2021-03-31 08:30:41 |
| Message-ID: | 20210331083041.peoupo5l3lxbks35@nol |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 31, 2021 at 03:48:16PM +0900, Kyotaro Horiguchi wrote:
>
> Thanks! However, Michael's suggestion is worth considering. What do
> you think about makeing NaN-involved comparison return NULL? If you
> agree to that, I'll make a further change to the patch.
As I mentioned in [1] I think that returning NULL would the right thing to do.
But you mentioned elsewhere that it would need a lot more work to make the code
work that way, so given that we're 7 days away from the feature freeze maybe
returning false would be a better option. One important thing to consider is
that we should consistently return NULL for similar cases, and having some
discrepancy there would be way worse than returning false everywhere.
[1] https://www.postgresql.org/message-id/20210330153940.vmncwnmuw3qnpkfa@nol
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sait Talha Nisanci | 2021-03-31 08:50:00 | Crash in record_type_typmod_compare |
| Previous Message | Fabien COELHO | 2021-03-31 08:02:42 | Re: pgbench - add pseudo-random permutation function |