From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | kenaniah <kenaniah(at)gmail(dot)com>, Pg Bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #6401: IS DISTINCT FROM improperly compares geomoetric datatypes |
Date: | 2012-01-19 13:40:33 |
Message-ID: | 4F181D51.4030402@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrea Grassi | 2012-01-19 15:20:10 | R: R: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function |
Previous Message | Alvaro Herrera | 2012-01-19 13:30:44 | Re: BUG #6401: IS DISTINCT FROM improperly compares geomoetric datatypes |