Re: Fixing r-tree semantics

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fixing r-tree semantics
Дата
Msg-id 7914.1119793923@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fixing r-tree semantics  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Fixing r-tree semantics  (Bruno Wolff III <bruno@wolff.to>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Fundamental error in "no WAL log" index/file creation
Следующее
От: Andrew Dunstan
Дата:
Сообщение: tsearch2 changes need backpatching?