Re: Fixing r-tree semantics - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixing r-tree semantics
Date
Msg-id 7914.1119793923@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing r-tree semantics  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fixing r-tree semantics
List pgsql-hackers
I wrote:
> Andrew - Supernews <andrew+nonews@supernews.com> writes:
>> Notice also that contrib/seg and contrib/cube have their own, and
>> incompatible, idea of what the semantics of &< and &> should be.

> Um.  Not sure what to do about these ... any opinions?

Having looked at this, I propose the following:

contrib/seg: fix the semantics of &< and &> to agree with box's
semantics.  There's no obvious usefulness to the way these operators
are defined now, and since the code is using the former rtree indexing
logic, they are clearly broken as-is.

contrib/cube: I quote from cube.c:

/* The following four methods compare the projections of the boxes  onto the 0-th coordinate axis. These methods are
uselessfor dimensions  larger than 2, but it seems that R-tree requires all its strategies  map to real functions that
returnsomething */
 

Now that the module uses GIST instead of r-tree, there's no very strong
reason why it should provide these operators at all.  I propose removing
all of << >> &< &> from contrib/cube, leaving only the four
n-dimensional indexing operators (&& ~= ~ @).

Any objections?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fundamental error in "no WAL log" index/file creation
Next
From: Andrew Dunstan
Date:
Subject: tsearch2 changes need backpatching?