Re: Fixing r-tree semantics

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