Re: linked list rewrite - Mailing list pgsql-hackers

Neil Conway <neilc@samurai.com> writes:
> The known remaining issues that need to be addressed are:
> (1) API naming

I'll keep my mouth shut about this one until some other people have had
a chance to weigh in...

> (3) Apply the work to CVS, and update the rest of the tree for the new 
> API

> The amount of integration work that needs to be done partially depends 
> on the resolution to #1, but either way the list rewrite will require a 
> lot of (relatively minor) changes scattered throughout the tree. What 
> is the best way to land these changes in HEAD with minimal disturbance 
> to other developers?

I'm not especially excited about the CVS-branch idea; I think that
you'll end up with a major merge headache, unless the branch lives for
such a short time that it'd hardly be worth doing anyway.  As I said
before, I'm willing to help out with the grunt-labor part of this so
that the change can be completed more swiftly.  If I'm doing that
instead of other stuff, that's one large source of code drift removed ;-)

What I would like to do is to set up compatibility macros along the
lines I suggested before, so that existing code will compile and work
as much as possible.  I am thinking that we'd actually leave the
compatibility macros in place indefinitely, but protected with a define
("#ifdef OLD_LIST_API" or some such).  This would make it easier for
people to deal with porting user-written code.  There are plenty of
scenarios where one would like a loadable module's source to compile
as-is against multiple backend versions, and that will be impossible
for anything that uses lists if we don't provide some hack like this.

The number of macros needed obviously depends on whether we rename
functions or not, but in any case the core of the thing would be
versions of lfirst, lnext, and foreach that cast their arguments so that
a pointer declared as List * can be misused as a list iteration variable.
There will be a small number of things that we cannot make work this
way, for instance applying lfirst to something that actually is a List
and not a ListCell, but I think we can make sure that all the commonly
used coding patterns work.

Given that, the work plan would look like this:

1. Finish up list.c and pg_list.h with compatibility macros; for the  moment, #define OLD_LIST_API.

2. Debug until regression tests pass.  This will entail finding the  places where the compatibility layer fails and
fixingthem.
 

3. Commit to CVS head.

4. Incrementally fix places that need API adjustment (locally turning  off OLD_LIST_API should be sufficient to locate
these). Commit as  the work is done, thereby avoiding any code drift problem.
 

5. Remove default definition of OLD_LIST_API.
        regards, tom lane