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@alvh.no-ip.org
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
