Bug reference: 19603 Logged by: Yuelin Wang Email address: 1217816127@qq.com PostgreSQL version: 19beta2 Operating system: Linux (Ubuntu 24.04, x86_64) Description:
### Summary
The static helper distance_1D() in contrib/cube/cube.c classifies two intervals as "left of", "right of", or "intersecting" using direct floating point comparisons. When a coordinate is NaN, every comparison evaluates to false, so the interval falls through to the intersecting branch and the function returns 0.0 instead of NaN. distance_taxicab and distance_chebyshev call distance_1D per dimension and sum or max the results, so a single NaN coordinate silently produces a finite, plausible-looking distance instead of propagating NaN as IEEE 754 arithmetic normally would.
A database user who stores or queries cube values containing NaN coordinates can get silently wrong distance results (e.g. 0 instead of NaN) from distance_taxicab and distance_chebyshev, which can corrupt nearest-neighbor search results, ranking, or KNN-index-backed queries that rely on these operators.
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.
