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

From Tom Lane
Subject Re: Fixing r-tree semantics
Date
Msg-id 19989.1119569900@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixing r-tree semantics  (Michael Fuhr <mike@fuhr.org>)
Responses Re: Fixing r-tree semantics
List 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 by date:

Previous
From: Greg Stark
Date:
Subject: Re: GiST rtree logic is not right
Next
From: Andrew Dunstan
Date:
Subject: language handlers in public schema?