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

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.

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.

--
Best regards,
Aleksander Alekseev