Re: Fixing r-tree semantics

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Fixing r-tree semantics
Дата
Msg-id 19989.1119569900@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Fixing r-tree semantics  (Michael Fuhr <mike@fuhr.org>)
Ответы Re: Fixing r-tree semantics  (William White <bwhite@frognet.net>)
Список pgsql-hackers
Michael Fuhr <mike@fuhr.org> writes:
> On Thu, Jun 23, 2005 at 05:59:25PM -0400, Tom Lane wrote:
>> Fixing the existing operators seems relatively straightforward; there will
>> need to be some extension to rtstrat.c to represent "NOT this operator"
>> as well as "this operator", but that's not hard.  I plan to do this, and
>> make the corresponding fixes in contrib/rtree_gist as well.

> Excellent.  If the fix is straightforward, is it going to be
> backpatched at least to 8.0?  Or is backpatching not worthwhile,
> considering that hardly anybody stumbles across the problem or
> complains about it?

In principle it could be backpatched, because this is just a change in
the search behavior and not a change in either catalog entries or rtree
index contents; hence no initdb needed.  However, given that the
behavior has been broken since the rtree code was written and nobody
noticed except bwhite, I think it's pretty low-priority to back-patch.
I find it more significant for 8.1 because (a) it's now more likely that
indexscans will get used for these queries, and (b) I'm thinking we
really ought to fold rtree_gist into the core so that we have at least
some built-in gist opclasses (for testing purposes if nothing else).
I started out looking for the bug in rtree_gist, and eventually realized
that it had slavishly copied rtree's bug...
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: GiST rtree logic is not right
Следующее
От: Andrew Dunstan
Дата:
Сообщение: language handlers in public schema?