Re: BUG #19705: One NaN box makes a BRIN box_inclusion_ops index omit unrelated rows

Hi Kirill,

Agreed on all four. v4 attached, split into BRIN and GiST.

0001 is BRIN, master only. bound_box() is untouched. The consistent
function also scans a range whose union is not mergeable with itself,
so old NaN summaries work without REINDEX. Needs a catversion bump.

0002 is GiST, back to 14. Old internal keys with a NaN match every
search and get KNN distance zero. Without the distance part, KNN on old
indexes returned rows out of order. 0002 also fixes point ~= with a NaN
query, which lost rows even on a fresh index. The leaf check used
FPeq(), but point_eq() compares exactly when there is a NaN.

The .nocfbot file is BRIN for the back branches, against REL_18. It
needs no catalog change. Consistent scans a range whose union does not
contain itself, using the existing contains support function. A NaN box
fails that, and any sane union passes. Nothing on disk changes, so old
indexes work without REINDEX after a minor upgrade. The code applies to
14 and later, the test hunk needs a small rebase on 14 to 16. This check
would also work on master, if we want one fix everywhere.

I checked 0001 and 0002 with indexes built by unpatched master, then
pg_upgraded, no REINDEX. The back branch patch got the same check on
REL_18, with a minor upgrade.

Thanks,
Shihao