Re: Fixing r-tree semantics

Tom Lane wrote:
> 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.

Well, leave it to me to find the obscure bugs in other people's code,
and miss the blatant ones in my own.

It's been awhile since I've looked at this and I've pretty much swapped
my PG interals knowledge out of my brain. As I recall you can (or
could) demonstrate the error with the default test suite, but you have
to forcibly override the search strategy cost constants so that PG will
actually do r-tree index searches (or maybe it was comparisons, it's
been awhile) instead of sequential scan. Check the thread, I think I
did send in a test case. In reality, with the default constants, you'd
need a rather large set before you saw any problems.

If anyone is curious, my intended application was time intervals. That
is to say, *real* mathematical intervals with two rational numbers as
endpoints, not just durations (displacements) which as I recall is what
SQL time "intervals" actually are. Frankly, I've always considered it a
serious oversight that PG doesn't provide this as a native type with its
own indexing and operators, especially given that the default r-tree
operators don't really work with right-open intervals (though that's
another rant). In any case 1D was pretty much universal, barring
radical changes to the spacetime continuum. I abandoned the project,
but not before writing a general set of 1D interval operators to handle
all cases of open and closed endpoints.

I was under the impression that a fix had already been applied, but it's
nice to see it happen. I say this because we discussed possible fixes
-- either changes to operator semantics or new operators -- and someone
with a wizard hat nodded in agreement.

-- Bill