Re: BUG #19603: Vuln47: distance_taxicab and distance_chebyshev silently return 0 instead of NaN when a cube coordin

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

In response to

Responses

Browse pgsql-bugs by date

  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