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. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
