Hi Manu,
Thanks for running the whole matrix again.
> I am happy to keep it out of scope for this set if you
> would rather handle a NaN in the query polygon separately.
I'd keep it out. Nothing stored in the index is wrong here. The NaN is
in the query, and the heap answer is wrong too. With the gist.sql test
table, a 0 to 99 grid, the polygon '(0,0),(0,10),(10,10),(10,NaN)'
matches 1015 rows on a seq scan, far more than any 10 by 10 square can
hold. point_inside() doesn't handle NaN, so the fix belongs there, as a
master only behavior change. I'll start a separate thread for it.
Where each patch would go:
0001 BRIN, master only, it adds a pg_amproc row.
v6-REL_18-0001 BRIN without catalog changes, 14 to 18.
0002 to 0004 GiST, 14 to 18. They need a small rebase on 18 because
of 1b105f9472b, and a bit more on 14.
I think the set is ready for a committer to look at.
Thanks,
Shihao
