On 19.01.2012 15:30, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of jue ene 19 07:25:36 -0300 2012:
Frankly that's such a rare corner case that I'm not very enthusiastic
about fixing it. One idea would be to look up the type's b-tree sort
operators, and pick the equality operator from there. But point datatype
doesn't have b-tree sort operators, either, so it wouldn't help in this
case.
It doesn't have a hash opclass either, which could be used as a fallback
in case there's no btree. Point cannot obviously have a btree opclass
(no inequalities), but a hash one seems possible.
It wouldn't be difficult to define b-tree operators for point, by
comparing x value first, then y, or something like that. If the index
operations are only used for equality lookups, it doesn't matter how the
< and > are defined as long as the system is self-consistent.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
