Neil Conway wrote:
> (1) API naming
>
> In the latest prototype implementation, I've adopted a completely new
> naming convention for the functions in the list API. The new API looks
> like:
>
> List *list_append(List *list, void *datum);
> List *list_prepend(List *list, void *datum);
> List *list_conc(List *list1, List *list2);
> bool list_member(List *list, void *datum);
> List *list_remove(List *list, void *datum);
> etc.
>
> Function variants which operate on integer lists (type = T_IntList)
> have an "_int" suffix, whereas OID list functions use an "_oid" suffix.
> By default, list operations use structural equality (i.e. equal()) --
> if a list function uses pointer equality to determine if two list
> elements are the same, it has the "_simple" suffix. And so on.
>
> In contrast, the existing List API is a lot more inconsistent (IMHO). I
> elaborated on some of the deficiencies of the existing API naming
> scheme here:
>
> http://archives.postgresql.org/pgsql-patches/2004-01/msg00188.php
>
> Tom objected to changing the names:
>
> http://archives.postgresql.org/pgsql-patches/2004-01/msg00186.php
> http://archives.postgresql.org/pgsql-patches/2004-01/msg00191.php
I agree a renaming of list functions is good. If we had kept the
original Berkeley code as-is, we would have a lot fewer developers
today. :-) Making drastic cleanups is often worthwile. I write
backend code and still can't remember which list function does what, so
clearer naming would help me a lot, and I am sure others too.
Tom had the idea of making compatible names for the old macros, and I
think that is an excellent compromise.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073