Alvaro Herrera <alvherre@xxxxxxxxxxxxxxx> writes: > Tom Lane wrote: >> Since type record *does* have btree/hash opclasses, it is not negotiable >> that the component column types obey btree or at least hash semantics. >> The only way to fix this would be to provide such opclasses for point. >> Btree has the probably-fatal obstacle that there's no plausible linear >> sort order for 2-D points. It would be possible to make hash work, if >> it weren't that point_eq() is fuzzy equality not exact equality. > This comment made me remember something I mentioned some months ago, > regarding fuzzy comparisons for other datatypes; > http://www.postgresql.org/message-id/20150512181307.GJ2523@xxxxxxxxxxxxxx > It seems that currently box_contains_pt() uses exact floating point > operators rather than fuzzy; we were pushing for having some of these > operators be changed to use the fuzzy definitions, and introduce a few > more fuzzy operators, to be used in BRIN opclasses. > I wonder if it would make sense to introduce a hash opclass for point > and other floating-point-based datatypes that uses strict equality, so > that IS [NOT] DISTINCT FROM works on them. Since there cannot be a > btree opclass for point, there shouldn't be any definitional problem in > doing so; but for datatypes that do have a linear sort order, maybe this > (having different equality operators for btree and hash) would be a > problem. The other line of attack would be to deprecate all the fuzzy comparison behavior in the geometric types, and just make it exact. Don't know how much pain that would add, but surely it would also subtract some. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
