> I'll look at problem after GiST concurrency. Fixing
> rtree_gist is bug a fix, not a new feature, so I'm not
> limited by 1 July.

Wont fixing rtree(_gist) require initdb, since the behaviour of the
operators will change?

.... John


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"John Hansen" <john@geeknet.com.au> writes:
>> I'll look at problem after GiST concurrency. Fixing
>> rtree_gist is bug a fix, not a new feature, so I'm not
>> limited by 1 July.

> Wont fixing rtree(_gist) require initdb, since the behaviour of the
> operators will change?

Possibly, but we never guarantee no initdb until final release anyway.

Teodor is right that this is a bug fix and so can be postponed on its
own terms. But moving rtree_gist into the core looks like a feature
change to me, so if that's going to happen it has to happen before
1 July. It would be a lot easier to sell that if it gave the right
answers ;-)

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tom Lane <tgl@sss.pgh.pa.us> writes:

> It would be a lot easier to sell that if it gave the right answers ;-)

Of course given that the real rtree index gives the wrong answers perhaps
moving rtree_gist into core (after fixing this) is just a bug fix

--
greg


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match