Re: BUG #6401: IS DISTINCT FROM improperly compares geomoetric datatypes

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

In response to

Browse pgsql-bugs by date

  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