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

Hi,

On Wed, 4 Nov 2026 at 15:06, Aleksander Alekseev
<aleksander(at)tigerdata(dot)com> wrote:
>
> Hi,
>
> > 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.

Thanks for checking, I missed those in v1. Attached is v2 in two parts.
The first uses the float8 helpers for comparisons and bound selection.

>
> I experimented more and discovered that GiST is broken in the same
> fashion. As an example:
>
> ```
> CREATE TABLE cube_nan (c cube);
>
> -- 100-dimensional cubes, so that 100 rows are already enough to build a
> -- two-level GiST index; every 7th row carries NaN coordinates
> INSERT INTO cube_nan
> SELECT CASE WHEN g % 7 = 0
> THEN cube(array_fill('nan'::float8, ARRAY[100]))
> ELSE cube(array_fill(g::float8, ARRAY[100]))
> END
> FROM generate_series(1, 100) g;
>
> CREATE INDEX ON cube_nan USING gist (c);
>
> SET enable_seqscan = off;
>
> SELECT c <-> cube(array_fill(0::float8, ARRAY[100])) AS dist
> FROM cube_nan ORDER BY dist;
> ```
>
> I believe we should treat this as an originally reported bug and fix it too.

Yes, I've included this in the second patch. AFAICS, NaN isn't a valid
lower bound for an internal key that also covers finite values, so I've
used -Infinity there.

FWIW, replacing the library and restarting doesn't repair existing
indexes with NaNs. REINDEX does, so I think we should mention that in
the release notes if we take these commits in.

Thoughts on v2?

Regards,
Ayush