Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

Next:From: Andrea GrassiDate: 2012-01-19 15:20:10
Subject: R: R: R: R: R: R: BUG #6342: libpq blocks forever in "poll" function
Previous:From: Alvaro HerreraDate: 2012-01-19 13:30:44
Subject: Re: BUG #6401: IS DISTINCT FROM improperly compares geomoetric datatypes

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group