Last chance to defend RTREE index access method

We previously discussed the idea of removing the rtree access method
in 8.2, on the grounds that GiST does everything rtree can do, only
better. Now that GiST has WAL support and can do concurrent access,
it's pretty hard to see why anyone would want to use rtree instead;
and I haven't heard anyone volunteering to bring rtree up to speed.

We already have GiST opclasses in core that correspond to the core
rtree opclasses. To arrange transparent migration of existing database
schemas, I believe it would be sufficient to put a kluge in DefineIndex
to substitute "gist" for "rtree" if it's asked to create an rtree index.

Any objections out there?

regards, tom lane