| From: | Aleksander Alekseev <aleksander(at)tigerdata(dot)com> |
|---|---|
| To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Cc: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>, 1217816127(at)qq(dot)com |
| Subject: | Re: BUG #19603: Vuln47: distance_taxicab and distance_chebyshev silently return 0 instead of NaN when a cube coordin |
| Date: | 2026-11-04 09:05:27 |
| Message-ID: | CAJ7c6TM7CNrQShuPapof77A6SoP-qqjpQX2q1C3B0HT4749T6A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Hi Ayush,
> Thanks for the report and repro.
>
> It looks to me like the root is distance_1D(): with a NaN coordinate none of
> its comparisons can be true, so it seems to fall through to the overlapping
> case and return 0. My first thought was to fix it there and return NaN when
> any endpoint is NaN, which seems enough for taxicab and Euclidean (<->), which
> accumulate with +=. Chebyshev needs a bit more, since its running max uses
> "d > distance" and NaN > x is false, so I added an explicit NaN check there too.
I noticed the patch on the commitfest and decided to take a look.
All in all it's good but there are several similar bugs that it
doesn't address (and which were not reported above):
```
=# CREATE EXTENSION cube;
=# SELECT '(1,1)'::cube = '(nan,nan)'::cube;
?column?
----------
t
=# SELECT '(nan)'::cube > '(1)'::cube; -- wrong because 'NaN' :: real
> 1.0 :: real
?column?
----------
f
```
I think it should.
--
Best regards,
Aleksander Alekseev
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2026-11-04 09:34:23 | Re: Wrong result: count(DISTINCT x COLLATE "C") with GROUP BY x on a nondeterministic collation |
| Previous Message | Richard Guo | 2026-11-04 07:47:57 | Re: Incorrect NOT IN results with implicit casts returning NULL after anti-join optimization |