kcwitt@gmail.com writes:
> Whatever issue there is with comparing points should be dealt with in
> postgres and not pushed to client applications.
The problem with this is that it's not entirely clear what definition of
"equality" IS [NOT] DISTINCT FROM should use.
The current definition is "use the operator named =", which is rather ad
hoc, but you can point to chapter and verse in the SQL standard where
X IS [NOT] DISTINCT FROM Y is defined in terms of "X = Y", so it's not
completely nuts either. Personally I'd prefer it to be defined as "use
the equality operator of the data type's default btree opclass, or hash
opclass if no btree opclass"; but it's likely that that would break some
cross-type cases that work today, so it wouldn't be a panacea.
But in either case, "point" loses because it has neither an operator
named "=" nor a btree or hash opclass. This is not just an oversight.
There is a "point ~= point" operator but it implements fuzzy equality,
making it unsuitable as a basis for btree or hash behavior, even assuming
that you could invent the linear ordering of points that would also be
needed for a btree opclass. It would surely not be terribly hard to
invent an exact-equality "=" operator for points, but it's not clear how
useful that would be. Almost all the existing operators for points are
fuzzy.
The same problems exist for other geometric types, usually worse, because
many of the others do have "=" operators but they compare areas :-(.
Nobody's really wanted to break backwards compatibility enough to bring
some sanity to that mess.
Short answer is I don't think this is likely to change in the near future.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
