Moving src/backend/utils/misc/rbtree.c to src/backend/lib

Peter Geoghegan suggested [1] moving rbtree.c to src/backend/lib, which
I think makes a lot of sense. Now that we have several other general
purpose data structures in src/backend/lib (linked lists, a binary heap,
and a pairing heap), rbtree.c would definitely be better placed in
src/backend/lib, too.

The usual objection to moving things is that it makes back-patching
harder. It also might break third-party code that use it (since
presumably we would also move the .h file). Nevertheless, I feel the
advantages outweigh the disadvantages in this case.

Any objections?

- Heikki

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> Peter Geoghegan suggested [1] moving rbtree.c to src/backend/lib, which
> I think makes a lot of sense. Now that we have several other general
> purpose data structures in src/backend/lib (linked lists, a binary heap,
> and a pairing heap), rbtree.c would definitely be better placed in
> src/backend/lib, too.

> The usual objection to moving things is that it makes back-patching
> harder. It also might break third-party code that use it (since
> presumably we would also move the .h file). Nevertheless, I feel the
> advantages outweigh the disadvantages in this case.

> Any objections?

A look at the git history says that rbtree.h/.c have not been touched
(except by copyright/pgindent commits) since 9.0, so probably the
backpatch argument doesn't have much force.

However, wasn't there some speculation about removing rbtree entirely?
If we're going to end up doing that, moving the files first is just
unnecessary thrashing.

regards, tom lane

On 12/22/2014 05:19 PM, Tom Lane wrote:
> However, wasn't there some speculation about removing rbtree entirely?

Not that I recall. It's still used for GIN bulk loading. There might be
better ways to do that, but there hasn't been any serious discussion on
that.

There was some discussion on replacing the existing binary heap usage
with the pairing heap, in MergeAppend and in tuplesort.c, but that's a
different story.

- Heikki

On Mon, Dec 22, 2014 at 5:16 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> Peter Geoghegan suggested [1] moving rbtree.c to src/backend/lib, which I
> think makes a lot of sense. Now that we have several other general purpose
> data structures in src/backend/lib (linked lists, a binary heap, and a
> pairing heap), rbtree.c would definitely be better placed in
> src/backend/lib, too.
>
> The usual objection to moving things is that it makes back-patching harder.
> It also might break third-party code that use it (since presumably we would
> also move the .h file). Nevertheless, I feel the advantages outweigh the
> disadvantages in this case.

I agree.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company