subversion vs cvs (Was: Re: linked list rewrite)

I'd like to wrap up the linked list rewrite, and get the code into CVS
reasonably soon. If you're unfamiliar with the motivations for
redesigning the linked list code, check the archives for previous
discussions, such as:

http://www.mail-archive.com/pgsql-patches(at)postgresql(dot)org/msg02204.html

http://www.mail-archive.com/pgsql-patches(at)postgresql(dot)org/msg01320.html

The basic idea is to ditch the Lisp-style linked list representation
(in which a "list" is merely a pointer to the head node), and adopt a
new List struct like so:

typedef struct List
{
NodeTag type; /* T_List, T_IntList, or T_OidList */
int length;
ListCell *head;
ListCell *tail;
} List;

This allows us to implement most of the important list operations
(length, prepend, append and concatenation) with constant time
complexity, and speed up some other operations (such as equality).

The known remaining issues that need to be addressed are:

(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 won't summarize Tom's cogent points here so as not to put words in
his mouth; however, please read those posts.)

I think changing the list API names is a good idea for a few reasons.
First and foremost, it improves the readability of the code and the
consistency of the list API. Second, one objection to changing the API
names is that it requires more changes to the rest of the tree. While
that's indisputable, I think we'll realistically need to visit the vast
majority of the List API call sites in order to implement the list
rewrite anyway, so in the long run I don't think changing the API names
will be that much extra work. Third, it has the benefit of cleanly and
totally breaking existing code that uses the List API, so that we don't
miss any List API call sites whose semantics have subtly changed (e.g.
a switch of a particular function from structural equality to pointer
equality).

So, would people prefer that we keep the old API names, or adopt the
new naming conventions?

(2) Remaining implementation work

The code has drifted a fair bit underneath the latest list rewrite
patch (which was incomplete anyway). It's unfortunately been a little
while since I've looked at the patch, but I don't recall there being
any showstopping problems that needed to be resolved --- it's just a
matter of wrapping up remaining loose ends. I'm going to get started on
this on today.

(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?

One possibility is to create a private CVS branch, implement any
necessary changes throughout the source tree and test all those
changes, and then merge the branch into HEAD once it is ready. This
would still break outstanding patches, as Tom has pointed out, but it
might reduce the disturbance to other developers. It doesn't really
matter to me whether this is done or not (I can do my own revision
control locally if there's a need for it), so speak up if you think
this would be worth doing.

Another possibility is to create some wrapper macros / functions that
would insulate the changes in the list API, so that we could make the
changes incrementally. Not sure how viable this is.

That's about it. Does anyone know of anything else that will need to be
tackled before we can merge the list rewrite?

Cheers,

Neil

Re changing APIs or not.

I agree with Tom that an incremental change is easier. More
importantly, it is also easier to test your implementation.

Even if everybody agrees that the API should be changed, IMO a better
way would be to first use your implementation with the old API and go
through some thorough testing to make sure it is AOK. Once we are
certain (or as certain as we can be) about that, you can changeover to
the new API. This way, when bugs show up we won't be left wondering if
its because of the new API interacting with some hidden assumption at
the call-sites or if it is only the implementation.

One step at a time seems safer to me.

I would think a new CVS branch would be the right way to merge your
stuff especially if you are going with the API change route. That way
you won't have to lock the tip and can incrementally work with a
broken branch until it is fine (and keep re-merging).

Which brings me to another question .. has anybody considered using
subversion instead of CVS ?

--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh

Neil Conway <neilc(at)samurai(dot)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 fixing them.

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

On Tue, 23 Mar 2004 08:39:21 -0800
Sailesh Krishnamurthy <sailesh(at)cs(dot)berkeley(dot)edu> wrote:

> Which brings me to another question .. has anybody considered using
> subversion instead of CVS ?

I for one would love to see more Open Source projects like PostgreSQL
move to using subversion instead of CVS. I've been using it for
awhile now on my little projects and it's a joy to work with.

---------------------------------
Frank Wiles <frank(at)wiles(dot)org>
http://frank.wiles.org
---------------------------------

On Mar 23, 2004, at 8:39, Sailesh Krishnamurthy wrote:

> Which brings me to another question .. has anybody considered using
> subversion instead of CVS ?

My guess would be only people who haven't used arch. :)

Seriously, though. Decentralized, disconnected revision control is a
lot nicer to work with in open source projects...especially larger ones
with more developers in more locations.

--
Dustin Sallings

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Tue, Mar 23, 2004 at 05:00:14AM -0500, Neil Conway wrote:

[...]

> The basic idea is to ditch the Lisp-style linked list representation
> (in which a "list" is merely a pointer to the head node), and adopt a
> new List struct like so:

I assume you are doing away with the FastList hack too, aren't you?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
We take risks not to escape from life, but to prevent life escaping from us.

Dustin Sallings <dustin(at)spy(dot)net> writes:
> On Mar 23, 2004, at 8:39, Sailesh Krishnamurthy wrote:
>> Which brings me to another question .. has anybody considered using
>> subversion instead of CVS ?

> My guess would be only people who haven't used arch. :)

This reminds me quite a lot of a discussion that was just happening on
a Red Hat mailing list. It seems the great thing about revision control
systems is there are so many to choose from ;-) ... and plenty of people
willing to proselytize for their favorite.

AFAICS, though, CVS is not broken for our needs. I don't see an
adequate reason to change.

regards, tom lane

Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> writes:
> I assume you are doing away with the FastList hack too, aren't you?

Yup, we'll get to revert that junk too.

regards, tom lane

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Neil Conway wrote:
>> Tom objected to changing the names:

> 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 would be satisfied if we kept the names of the core,
most-commonly-used functions the same. I would put lfirst, lnext,
lcons, lappend, length, maybe member into the category of names
I don't want to change. Attaching "_int" and "_oid" to those for the
related functions is okay.

If we go in that direction then the common prefix would be just "l"
and not "list_", which seems a good idea to me on grounds of brevity.
Looking over Neil's proposal again, one of the things that bugged me
about it was that the function names were overly verbose. That's okay
for stuff you don't see often, but the common list functions are *all
over* the backend. You can't really claim that developers will be
unfamiliar with them. Making those names longer won't buy us anything
except sooner onset of carpal tunnel syndrome.

regards, tom lane

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Neil Conway wrote:
> >> Tom objected to changing the names:
>
> > 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 would be satisfied if we kept the names of the core,
> most-commonly-used functions the same. I would put lfirst, lnext,
> lcons, lappend, length, maybe member into the category of names
> I don't want to change. Attaching "_int" and "_oid" to those for the
> related functions is okay.
>
> If we go in that direction then the common prefix would be just "l"
> and not "list_", which seems a good idea to me on grounds of brevity.
> Looking over Neil's proposal again, one of the things that bugged me
> about it was that the function names were overly verbose. That's okay
> for stuff you don't see often, but the common list functions are *all
> over* the backend. You can't really claim that developers will be
> unfamiliar with them. Making those names longer won't buy us anything
> except sooner onset of carpal tunnel syndrome.

Agreed. Sounds like a plan.

What does the 'n' stand for in ncons? I also felt that lcons
(construct) and nconc(concat) were too similarly named.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> What does the 'n' stand for in ncons? I also felt that lcons
> (construct) and nconc(concat) were too similarly named.

I think nconc is a direct copy from the Lisp original; whatever its
origins are, they're back in Lisp prehistory. I don't mind renaming
that one ;-)

Let's see ... fleshing out this idea a bit, here's a rundown of all the
symbols in pg_list.h and suggested new names:

ListCell accessors:

lfirst no change
lfirsti lfirst_int
lfirsto lfirst_oid
lnext no change
foreach no change

List accessors:

length no change

lfirstcell new function to get first cell, or NULL if none

lfirst rewrite as lfirst(lfirstcell()) when applied to a List

lsecond, lthird, lfourth not clear if worth keeping

llastnode llastcell

llast Perhaps rewrite as lfirst(llastcell()) instead of keeping

makeListN list_makeN or possibly list_make_N
makeListiN list_makeN_int or list_make_N_int
makeListoN list_makeN_oid or list_make_N_oid

lcons no change
lconsi lcons_int
lconso lcons_oid

lappend no change
lappendi lappend_int
lappendo lappend_oid

nconc list_concat
We might also need a function to attach some bare ListCells to a List

nth list_nth
list_nth_int
list_nth_oid
Should add list_nth_int, list_nth_oid, even though there are no
corresponding functions at the moment

member list_member
ptrMember list_member_ptr
intMember list_member_int
oidMember list_member_oid

LispRemove list_remove
lremove list_remove_ptr
lremovei list_remove_int
list_remove_oid add, though not currently used

ltruncate list_truncate

set_union list_union
set_ptrUnion list_union_ptr
list_union_int not currently used
set_uniono list_union_oid

set_difference list_difference
set_ptrDifference list_difference_ptr
list_difference_int not currently used
set_differenceo list_difference_oid

equali and equalo become just calls on equal()

freeList list_free (frees only List, not pointed-to objects)

listCopy list_copy (shallow copy of List only)

A couple of notes here: I propose using the suffix "_ptr" for operations
that use pointer equality rather than equal(). Neil proposed "_simple"
but that seems less than clear to me --- which one is "simple" and which
isn't? Also, for the "set" operations I have just "list_union" etc
where Neil proposed "list_set_union".

Neil proposed inventing "list_deep_copy" which as far as I can see is
entirely redundant with copyObject. Similarly I can't see any value in
list_equal when equal() will do the trick.

regards, tom lane

I wrote:
> Let's see ... fleshing out this idea a bit, here's a rundown of all the
> symbols in pg_list.h and suggested new names:

Sheesh ... I forgot that I intended to do s/list_/l/g on that.

Doing so brings up one problem, which is that the old version of
lremove() conflicts with the new naming convention (it should have
had a name mentioning "ptr"). In the attached I work around this
by using "ldelete" rather than "lremove" as the base name for these
functions, but I'm open to other ideas.

ListCell accessors:

lfirst no change
lfirsti lfirst_int
lfirsto lfirst_oid
lnext no change
foreach no change

List accessors:

length no change

lfirstcell new function to get first cell, or NULL if none

lfirst rewrite as lfirst(lfirstcell()) when applied to a List

lsecond, lthird, lfourth not clear if worth keeping

llastnode llastcell

llast Perhaps rewrite as lfirst(llastcell()) instead of keeping

makeListN lmakeN or possibly lmake_N
makeListiN lmakeN_int or lmake_N_int
makeListoN lmakeN_oid or lmake_N_oid

lcons no change
lconsi lcons_int
lconso lcons_oid

lappend no change
lappendi lappend_int
lappendo lappend_oid

nconc lconcat
We might also need a function to attach some bare ListCells to a List

nth lnth
lnth_int
lnth_oid
Should add lnth_int, lnth_oid, even though there are no
corresponding functions at the moment

member lmember
ptrMember lmember_ptr
intMember lmember_int
oidMember lmember_oid

LispRemove ldelete
lremove ldelete_ptr
lremovei ldelete_int
ldelete_oid add, though not currently used

ltruncate no change

set_union lunion
set_ptrUnion lunion_ptr
lunion_int not currently used
set_uniono lunion_oid

set_difference ldifference
set_ptrDifference ldifference_ptr
ldifference_int not currently used
set_differenceo ldifference_oid

equali and equalo become just calls on equal()

freeList lfree (frees only List, not pointed-to objects)

listCopy lcopy (shallow copy of List only)

regards, tom lane

Tom Lane wrote:
> lcons no change
> lconsi lcons_int
> lconso lcons_oid
>

Should these be lnew or something clearer than cons-truct?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > What does the 'n' stand for in ncons? I also felt that lcons
> > (construct) and nconc(concat) were too similarly named.
>
> I think nconc is a direct copy from the Lisp original; whatever its
> origins are, they're back in Lisp prehistory. I don't mind renaming
> that one ;-)

I found out why it is called Nconc:

The name comes from CommonLisp: 'conc' for 'concatenate', prefixed by
the 'n' which signals a dangerous function modifying existing lists.
(Think of as as n-for-nuke.)

from:

http://www.muq.org/~cynbe/muq/mufref_437.html

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Tom Lane wrote:
>> lcons no change
>> lconsi lcons_int
>> lconso lcons_oid

> Should these be lnew or something clearer than cons-truct?

No, lcons is one of the names that I think we should stick with on
historical grounds. It's widely used in the backend and it has the
right connotations for anyone who's ever used Lisp. "lnew" conveys
nothing, certainly not the right thing (it doesn't make a new List,
only a new ListCell).

regards, tom lane

On 23-Mar-04, at 7:05 PM, Tom Lane wrote:
> No, lcons is one of the names that I think we should stick with on
> historical grounds. It's widely used in the backend and it has the
> right connotations for anyone who's ever used Lisp.

I think it has exactly the *wrong* connotations: the name suggests that
it creates a new cons cell (along with the ensuing implications about
performance and the internal implementation of the list), which is no
longer the case.

How about lprepend()? That allows for some symmetric with lappend().

-Neil

Neil Conway wrote:
> On 23-Mar-04, at 7:05 PM, Tom Lane wrote:
> > No, lcons is one of the names that I think we should stick with on
> > historical grounds. It's widely used in the backend and it has the
> > right connotations for anyone who's ever used Lisp.
>
> I think it has exactly the *wrong* connotations: the name suggests that
> it creates a new cons cell (along with the ensuing implications about
> performance and the internal implementation of the list), which is no
> longer the case.
>
> How about lprepend()? That allows for some symmetric with lappend().

Wow, I like that one!

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:

> Which brings me to another question .. has anybody considered using
> subversion instead of CVS ?

Why? not that I'm for a chance from something that isn't broken, but what
advantages does subversion give us over what we already have?

----
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: scrappy(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

Neil Conway <neilc(at)samurai(dot)com> writes:
> On 23-Mar-04, at 7:05 PM, Tom Lane wrote:
>> No, lcons is one of the names that I think we should stick with on
>> historical grounds. It's widely used in the backend and it has the
>> right connotations for anyone who's ever used Lisp.

> I think it has exactly the *wrong* connotations: the name suggests that
> it creates a new cons cell (along with the ensuing implications about
> performance and the internal implementation of the list), which is no
> longer the case.

How do you mean it's no longer the case? ListCell looks exactly like a
cons cell to me.

regards, tom lane

>>>>> "Marc" == Marc G Fournier <scrappy(at)postgresql(dot)org> writes:

Marc> On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:
>> Which brings me to another question .. has anybody considered
>> using subversion instead of CVS ?

Marc> Why? not that I'm for a chance from something that isn't
Marc> broken, but what advantages does subversion give us over
Marc> what we already have?

I've had plenty of pain with cvs in terms of directories not being
first-class etc .. but I don't really contribute to pgsql so you guys
probably don't have the same experience.

I was just curious as it looks like eventually subversion (or arch :-)
will be an alternative to cvs.

--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh

On 23-Mar-04, at 10:31 PM, Tom Lane wrote:
> How do you mean it's no longer the case? ListCell looks exactly like a
> cons cell to me.

Sorry, thinko on my part. I meant to say that lcons() is a Lispy name,
which suggests a Lispy implementation. This is no longer the case.
While lcons() isn't that bad of a name, I think it is more confusing
than it is helpful.

It just doesn't strike me that "construction" is a very useful way to
talk about what this operation is actually doing, and is asymmetric
with lappend() for no good reason. The operation is "prepending" an
element to an existing list, so why not give it a name that reflects
that?

-Neil

Neil Conway <neilc(at)samurai(dot)com> writes:
> It just doesn't strike me that "construction" is a very useful way to
> talk about what this operation is actually doing, and is asymmetric
> with lappend() for no good reason. The operation is "prepending" an
> element to an existing list, so why not give it a name that reflects
> that?

Historic practice. Sure, it's accident that lappend() is called what it
is, and it's accident that lcons() is called what it is, but there's not
adequate reason to rename either IMHO. You might as well argue that
begin/end are asymmetric and we ought to use begin/nigeb. (BTW I come
from a generation of programmers that actually did that sort of thing,
but fortunately the idea has mostly died out...)

Basically my argument is that we ought to preserve the well-entrenched
list function names. I'm prepared to grant that, say, set_ptrDifference
is not well known and can be renamed at little cost. I don't see the
cost-benefit argument for renaming lcons. There are real cognitive
costs to changing commonly known names, and this surely qualifies as one.

regards, tom lane

Neil Conway <neilc(at)samurai(dot)com> writes:
> [ replace lcons with lprepend ]

BTW ... you may or may not consider this relevant, but "prepend" is not
a word, it's only a hackish neologism. I can't find it at all in Random
House, and the Oxford English Dictionary lists it only as a "v. rare"
synonym for premeditate. So I don't think there's much ground to argue
that it obviously conveys the right thing as compared to "cons".

regards, tom lane

On Tue, Mar 23, 2004 at 01:16:51PM -0500, Bruce Momjian wrote:
> 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.

Maybe I already ask, is there any coding style recommendation for _new_
written things?

I agree with Bruce. The list functions and a lot of other functions
can be candidates for rename. I read Mono docs last night and
it's perfect if they can write to docs about functions names:
"mono_<type>_<action>".

I think sometime are people too much focus on the shortest way to
target and forgot that with code work others people and not CPU only.
(sorry of this pontification:-)

Karel

--
Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/

On Mar 23, 2004, at 11:45, Tom Lane wrote:

> AFAICS, though, CVS is not broken for our needs. I don't see an
> adequate reason to change.

Yes, of course. I guess my point is that if you're going to move away
from CVS, please don't just jump to ``slightly better CVS.''

I'm looking forward to a world with more open source projects in
distributed revision control. The ones I'm tracking and doing personal
branches against (vim, tla, a couple of other small projects) are
liberating.

Branching a tree I didn't expect to even have to edit while on an
airplane recently was a very pleasant experience. Actually, being able
to branch without thinking about the horrible consequences of CVS has
been wonderful in general.

As long as CVS works for you, though, you should continue to use it.

--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin(at)spy(dot)net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

After a long battle with technology, scrappy(at)postgresql(dot)org ("Marc G. Fournier"), an earthling, wrote:
> On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:
>
>> Which brings me to another question .. has anybody considered using
>> subversion instead of CVS ?
>
> Why? not that I'm for a chance from something that isn't broken, but what
> advantages does subversion give us over what we already have?

It's a newer design, offering some nice features:

- Directories, renames, and file meta-data are versioned.
- Commits are truly atomic. (DB guys should like that :-).)
- Branching and tagging are cheap (constant time) operations
- Costs are proportional to change size, not data size
- Efficient handling of binary files
- Parseable output (one of the things better about SCCS than RCS/CVS)

Unfortunately, they have only just gotten to the point of having a
"stable" version. Until very recently, different versions of
Subversion couldn't expect to talk to one another, which is a Very Bad
Thing.

In another year, it might be worth holding a debate over whether there
is value to considering Subversion or one of the Arch descendants as
an alternative to CVS. I wouldn't think it's time yet. And it would
be as wise to consider Arch as well; it has some pretty interesting
"repository" features...
--
let name="cbbrowne" and tld="cbbrowne.com" in name ^ "@" ^ tld;;
http://www3.sympatico.ca/cbbrowne/multiplexor.html
"Those who doubt the importance of a convenient notation should try
writing a LISP interpreter in COBOL or doing long division with Roman
numerals." -- Hal Fulton

On Tue, 23 Mar 2004 23:03:03 -0400 (AST)
"Marc G. Fournier" <scrappy(at)postgresql(dot)org> wrote:

> On Tue, 23 Mar 2004, Sailesh Krishnamurthy wrote:
>
> > Which brings me to another question .. has anybody considered using
> > subversion instead of CVS ?
>
> Why? not that I'm for a chance from something that isn't broken, but
> what advantages does subversion give us over what we already have?

Subversion has lots of "little" benefits, but nothing that would be
a major incentive to switch. The biggest benefits I can think of
of the top of my head are:

* Commits are actually atomic
* protocol sends diffs in both directions which speeds up everything
* branching and tagging are cheap constant time operations

* the time it takes to make changes is based on the size of the
change, not the size of the project

* whole directories are versioned not just files. So for example
if you for some reason wanted to rename src/backend/bootstrap.c
to src/backend/bootup.c you wouldn't lose your revision history
information. Same thing goes for complete reorganizations of the
file layouts.

* You can checkout "parts" of a project so if you need to fix a
bug in 7.3.6's src/backend/ you only have to transfer that portion
to you.

* cvs diff ( well svn diff ) can be done offline. Same with 'status'
which shows you your local modifications and 'revert' which reverts
your changes back to your last checkout/update/etc.

* Revisions numbers are repository wide instead of by file. You can
refer to revision #14328 on hackers and everyone knows exactly what
you are talking about and can switch their working copies to it
easily ( svn switch -r 14328 ). It's sort of like having a tag
for every commit made to the repository.

It does have some downsides that I have found, most notibly that the
size of your sources you have in your working copy are essentially
doubled. There is a copy in your .svn directory that allows the
offline status, diff, and revert commands to work.

---------------------------------
Frank Wiles <frank(at)wiles(dot)org>
http://frank.wiles.org
---------------------------------

On Mar 24, 2004, at 7:29, Frank Wiles wrote:

> [cool feature list]

Arch has all of that except for the checking out part of a directory
thing (would you really just check out the backend, submit a change,
and not build and test it?).

Additionally:

* Repositories can be easily replicated so checkouts don't have to
cross slow networks. I replicate every repository I work with to every
machine I use. This is not only my backup strategy, but it makes
checkouts faster.

* You can work completely offline. In addition to being able to diff,
undo changes, redo changes, etc... while offline, you can completely
branch a project do multiple commits, and merge them back into the main
archive when your plane lands.

* Branches are not only cheap, but can easily cross repository
boundaries. Any given user can create a branch from the head-of-line
tree and maintain changes, and the head-of-line maintainers can pull
those changes back in.

* Its storage is immutable. It never modifies a file so it does not
provide any possibility for corruption. This is also what makes
replication so trivial.

* Changesets have cryptographic checksums and may be cryptographically
signed. Checkouts are authenticated against both of these.

* Repositories can be accessed via a wide variety of means. Most of
mine are local file, WebDAV, or SFTP. I allow read-only access via
plain HTTP for anyone who wants to check out one of my projects.

* Files can be tracked in a nearly (or completely) automatic fashion.
Depending on project configuration, you can avoid having to interact
with the revision control system other than writing changelogs and
submitting patches. You an also use CVS-style tracking (manual adds
and deletes (plus moves)) if you're more comfortable that way.

* The design is way, way more simple and transparent, there are far
fewer requirements. At least for me, this translates to a higher
confidence that my stuff will always be available.

The advantage I see to Subversion is that it's designed to be a better
CVS. Since many people are comfortable with CVS and that style of
centralized development, it may feel a little more natural for new
converts. I feel that that's because it doesn't seem to take you very
far.

--
Dustin Sallings

Sailesh Krishnamurthy wrote:
> I've had plenty of pain with cvs in terms of directories not being
> first-class etc .. but I don't really contribute to pgsql so you guys
> probably don't have the same experience.
>
> I was just curious as it looks like eventually subversion (or arch :-)
> will be an alternative to cvs.

Eventually it (either subversion, or arch, or something else) will. You
just have to be patient :-) The movement will be very slow, we'll
probably see Apache 1.3.x disappear first before we see CVS disappear.

It _is_ frustrating to have to use something new, especially something
so frequently used like source control tool.

--
dave

Frank Wiles wrote:
>>Why? not that I'm for a chance from something that isn't broken, but
>>what advantages does subversion give us over what we already have?
>
> Subversion has lots of "little" benefits, but nothing that would be
> a major incentive to switch. The biggest benefits I can think of
> of the top of my head are:
>
> * Commits are actually atomic
> * protocol sends diffs in both directions which speeds up everything
> * branching and tagging are cheap constant time operations
> * the time it takes to make changes is based on the size of the
> change, not the size of the project
> * whole directories are versioned not just files. So for example
> if you for some reason wanted to rename src/backend/bootstrap.c
> to src/backend/bootup.c you wouldn't lose your revision history
> information. Same thing goes for complete reorganizations of the
> file layouts.

Actually, the things you mentioned are pretty "major", as most of the
above are really broken/painful to do/very slow in CVS. But, all of
those probably will not motivate a seasoned CVS user enough to migrate.

So one might ask, what *will* motivate a die-hard CVS user? A real-close
Bitkeeper clone? :-)

--
dave

On Mar 24, 2004, at 11:45, David Garamond wrote:

> So one might ask, what *will* motivate a die-hard CVS user? A
> real-close Bitkeeper clone? :-)

Since it's illegal for anyone who uses Bitkeeper's free license to
contribute to another project, does anyone know if there are any
features in Bitkeeper missing from arch (specifically tla) that matter
to developers? Or is there anything that may be a better match than
arch?

Unfortunately, I have never and will never use Bitkeeper unless
someone buys me a license for some reason. The distributed model seems
like the only way to go for the open source development of the future.

--
Dustin Sallings

Dustin Sallings wrote:
> On Mar 24, 2004, at 11:45, David Garamond wrote:
>
>> So one might ask, what *will* motivate a die-hard CVS user? A
>> real-close Bitkeeper clone? :-)
>
> Since it's illegal for anyone who uses Bitkeeper's free license to
> contribute to another project, does anyone know if there are any
> features in Bitkeeper missing from arch (specifically tla) that matter
> to developers? Or is there anything that may be a better match than arch?

From what I read here and there, BitKeeper excels primarily in merging
(good merging is apparently a very complex and hard problem) and GUI stuffs.

> Unfortunately, I have never and will never use Bitkeeper unless
> someone buys me a license for some reason. The distributed model seems
> like the only way to go for the open source development of the future.

Not necessarily. For small to medium projects, a centralized model might
work better.

--
dave

Andrew Dunstan wrote:
> (btw, if you want to work offline, which i saw referred to a couple of
> times, wouldn't cvsup do most of the job?).

From what I understand, a "distributed" source control means each
developer gets his own _repository_, not just a working copy. This means
you can commit to your own repo and even accept patches (either from the
master repo, other developer's repo, or from a 3rd party). In Linux
analogy, each developer can become an Alan Cox and maintain his own -ac
line.

From what I understand, CVSup is a tool to mirror the repository. It
doesn't allow each copy of the repository gets independently developed,
and then transferring around the modifications, or does it?

--
dave

On Mar 24, 2004, at 13:22, David Garamond wrote:

> From what I read here and there, BitKeeper excels primarily in merging
> (good merging is apparently a very complex and hard problem) and GUI
> stuffs.

There's not a lot of GUI in arch, but star-merge is fairly incredible.
This is how tla (the main arch implementation) itself is developed.
Lots of branches in lots of archives by lots of people.

>> Unfortunately, I have never and will never use Bitkeeper unless
>> someone buys me a license for some reason. The distributed model
>> seems like the only way to go for the open source development of the
>> future.
>
> Not necessarily. For small to medium projects, a centralized model
> might work better.

I make use of the distributed nature of arch in my personal projects
with no other developers. Offline work is just a branch in another
archive that gets merged in later.

Arch supports a centralized model as well as anything else, and I've
got a big centralized set of archives, but I don't always have good
connectivity to the master. This is where the distributed model wins.
A server/network/whatever outage does not have the opportunity to slow
me down. In the worst case, a long outage causes my branch to drift a
little further from head of line than it normally would.

--
Dustin Sallings

> It does have some downsides that I have found, most notibly that the
> size of your sources you have in your working copy are essentially
> doubled. There is a copy in your .svn directory that allows the
> offline status, diff, and revert commands to work.

What's needed is a good window client like WinCVS, however...

Chris

Christopher Kings-Lynne wrote:
>
> What's needed is a good window client like WinCVS, however...
>
> Chris
>

There is a number of those, our shop uses (and makes programs for) both
windows and unix (and might soon use mac's aswell), so it's very
important that there exists a good client for each. Especially if you
version html pages and such that is edited by people that isn't so techy.

We're using TortoiseSvn right now, it's implemented as an explorer
extension, so you just rightclick on a file or directory to
update/commit/whatever.

What i like with svn is that it's a nobrainer for old cvs guys like me
to use it. It solves all the problems with CVS right now, and promises
more features later on (like much better than CVS merging).

The new buzz is distributed versioning systems these days, but i
question if that is called for in the vast majority of projects out there.

If the only reason is for offline work that can be achieved with
subversion too, with svk for example (haven't tried it, but been told
that it works fine). Svk handles or will(?) handle distributed repos in
the bk sense aswell, i believe.

But ofcourse arch has alot of features that are extremly cool, the
reason why i didn't evaluate it further was that it didn't work on
windows well, the fixed weird branching/version naming and the
complexity of learning for our developers since they already use cvs.

Surely the two systems should be evaluated against their competiors
within the same distribution models, not cross the boundries, since the
design is very different.

Subversions strength is it's percieved simplicity, and archs strength is
it's complexity.

Regards,
Magnus

On Mar 24, 2004, at 18:22, Magnus Naeslund(t) wrote:

> The new buzz is distributed versioning systems these days, but i
> question if that is called for in the vast majority of projects out
> there.

You can use distributed revision control systems as centralized
systems, but not vice-versa.

> But ofcourse arch has alot of features that are extremly cool, the
> reason why i didn't evaluate it further was that it didn't work on
> windows well, the fixed weird branching/version naming and the
> complexity of learning for our developers since they already use cvs.

Depends on how you set it up. In the recommended ``tagline'' method,
you don't have to tell the revision control system when you add,
remove, or move files (for the most part, binary files are not suitable
for tagline). All you have to do is commit and type a message.

> Subversions strength is it's percieved simplicity, and archs strength
> is it's complexity.

It is subversion's complexity that drove me away from it, in fact.

Arch is incredibly simple all the way through. It sounds like it must
be complex to be able to do all of the things people do with it, but
it's most assuredly not. The requirements are few and basic (diff,
patch, and tar). The most common stuff is at least as simple as CVS
(commit, update and in explicit mode, add, rm, and mv), and the
advanced stuff is just as easy as the simple stuff (star-merge, tag
(branching), etc...).

As far as understanding the simplicity of arch (if you wanted to
understand the problems it solves and implement it yourself), a really
good presentation was posted today to the arch list that sums it up
quickly and concisely. It's hard to go through that and not think, ``I
could write this.''

http://web.verbum.org/tla/grokking-arch/grokking-arch.html

--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin(at)spy(dot)net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

On Wednesday 24 March 2004 06:03 pm, Dustin Sallings wrote:
> There's not a lot of GUI in arch, but star-merge is fairly incredible.
> This is how tla (the main arch implementation) itself is developed.
> Lots of branches in lots of archives by lots of people.

I would guess that better merging might be a real motivation for people. If a
patch that takes a month to develop can still apply cleanly despite
significant code drift in the interrem, I could see that as a real motivating
factor.

Matthew

"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
> I would guess that better merging might be a real motivation for
> people. If a patch that takes a month to develop can still apply
> cleanly despite significant code drift in the interrem, I could see
> that as a real motivating factor.

Not here. You want me to trust some bit of code (with absolutely zero
understanding of the source text it's hacking on) to figure out how to
resolve conflicting patches? That sounds like a recipe for big-time
unhappiness.

regards, tom lane

On Mar 24, 2004, at 20:29, Tom Lane wrote:

> Not here. You want me to trust some bit of code (with absolutely zero
> understanding of the source text it's hacking on) to figure out how to
> resolve conflicting patches? That sounds like a recipe for big-time
> unhappiness.

The idea is that it's the responsibility of the branch owner to keep
it up-to-date. For example, I've got a branch of tla (an arch
implementation) I made soon after I started using it in order to add a
command I wanted and refactor a bit of the insides. Over time, a lot
of stuff has changed, but I still want my stuff to work, so as I update
my branch against head of line, I make minor changes to it as things
go.

The difference is that instead of having a patch sitting in a queue
somewhere suffering from bit-rot, you've got a pointer to a branch that
you can merge when you get around to it. You can still view it as a
diff if you want, but the diff you get six months after the original
submission may be quite a bit different from what you would've got at
the beginning if a lot of the code around it has changed.

It's definitely not a magic tool that makes bad code good and
conflicting patches happy. It solves other problems, though. Many of
the problems you don't realize you have until you go back to something
else and try to do something simple like undo all of the changes you've
made since your last checkin.

--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin(at)spy(dot)net>
| Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

On 25-Mar-04, at 12:25 AM, Dustin Sallings wrote:
> It's definitely not a magic tool that makes bad code good and
> conflicting patches happy. It solves other problems, though.

I don't think anything mentioned in this thread so far would be an
enormous improvement over what we have now. However, I am still open to
trying Arch or SVN: in the long run, I think the productivity gain from
even an incremental improvement in the development toolset is worth a
little effort in relearning and migration.

But as I said, I don't think it's a critical issue, and if other
developers would rather we stick with what we have, that's fine with
me.

WRT the relative merits of CVS, Arch, and SVN, David Wheeler (of
Bricolage) has written an interesting article comparing the three
systems:

http://www.dwheeler.com/essays/scm.html

I think the lack of good Win32 support (unless rectified before the
release of 7.5) is a pretty major problem with Arch -- that alone might
be sufficient to prevent us from adopting it.

-Neil

Dustin Sallings wrote:

> On Mar 24, 2004, at 20:29, Tom Lane wrote:
>
>> Not here. You want me to trust some bit of code (with absolutely zero
>> understanding of the source text it's hacking on) to figure out how to
>> resolve conflicting patches? That sounds like a recipe for big-time
>> unhappiness.
>
> The idea is that it's the responsibility of the branch owner to keep
> it up-to-date. For example, I've got a branch of tla (an arch
> implementation) I made soon after I started using it in order to add a
> command I wanted and refactor a bit of the insides. Over time, a lot
> of stuff has changed, but I still want my stuff to work, so as I update
> my branch against head of line, I make minor changes to it as things
> go.
>
> The difference is that instead of having a patch sitting in a queue
> somewhere suffering from bit-rot, you've got a pointer to a branch that
> you can merge when you get around to it. You can still view it as a
> diff if you want, but the diff you get six months after the original
> submission may be quite a bit different from what you would've got at
> the beginning if a lot of the code around it has changed.

The difference here is that instead of submitting a patch for review,
which is then frozen, the branch owner can (and that means some will, no
matter what your intentions are) keep modifying the branch during the
review process, other than just keeping it in sync with conflicting
changes to the trunk. How do you plan to prevent that?

Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #

On Thu, Mar 25, 2004 at 08:05:05AM -0500, Jan Wieck wrote:

> The difference here is that instead of submitting a patch for review,
> which is then frozen, the branch owner can (and that means some will, no
> matter what your intentions are) keep modifying the branch during the
> review process, other than just keeping it in sync with conflicting
> changes to the trunk. How do you plan to prevent that?

I think it's much better for the reviewer to be able to see the history
of changes of the patch (branch), without having to look at the whole
patch again every time a small change is made to it.

Or do you diff two versions of a patch to see if the author only changed
what he says he changed? Wow, a diff of a diff, _that_ should be
difficult to read.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Use it up, wear it out, make it do, or do without"

Neil Conway said:

> I don't think anything mentioned in this thread so far would be an
> enormous improvement over what we have now. However, I am still open to
> trying Arch or SVN: in the long run, I think the productivity gain
> from even an incremental improvement in the development toolset is
> worth a little effort in relearning and migration.
>

ISTM what we have here is a solution in search of a problem. When the
committers tell us that there is a problem we should start looking.

> But as I said, I don't think it's a critical issue, and if other
> developers would rather we stick with what we have, that's fine with
> me.
>

Maybe we should look at providing SVN as a project option on the new
PGFoundry. That might let at least a part of the community get its toes
wet with it, without disrupting the core in the first instance.

>
> I think the lack of good Win32 support (unless rectified before the
> release of 7.5) is a pretty major problem with Arch -- that alone might
> be sufficient to prevent us from adopting it.
>

Agreed. It's a killer from my POV.

cheers

andrew

Dustin Sallings wrote:

>
> You can use distributed revision control systems as centralized
> systems, but not vice-versa.
>

Not true, the other way around exists, that is what svk does.

> As far as understanding the simplicity of arch (if you wanted to
> understand the problems it solves and implement it yourself), a really
> good presentation was posted today to the arch list that sums it up
> quickly and concisely. It's hard to go through that and not think, ``I
> could write this.''
>
> http://web.verbum.org/tla/grokking-arch/grokking-arch.html
>

Will read it, thanks.

Regards,
Magnus

On Mar 25, 2004, at 1:21, Neil Conway wrote:

> I think the lack of good Win32 support (unless rectified before the
> release of 7.5) is a pretty major problem with Arch -- that alone
> might be sufficient to prevent us from adopting it.

I don't do Windows, but my understanding is that tla is as well
supported on Windows as postgres is.

The design is fundamentally easy enough that a Windows user who cares
could probably make a more suitable port for Windows than the UNIX guys
are interested in making. I've seen such discussions on the list.

--
Dustin Sallings

On Mar 25, 2004, at 5:05, Jan Wieck wrote:

> The difference here is that instead of submitting a patch for review,
> which is then frozen, the branch owner can (and that means some will,
> no matter what your intentions are) keep modifying the branch during
> the review process, other than just keeping it in sync with
> conflicting changes to the trunk. How do you plan to prevent that?

You do both. Changesets are immutable. A patch cannot be modified.
However, new patches can be added for tracking changes to the tree.
You can review the original diff, and you can review how it's tracked
head-of-line changes independently. You can take the original diff and
manually wedge it in if you want, or you can see how the latest
progress differs before submission.

--
Dustin Sallings

On Mar 25, 2004, at 9:22, Magnus Naeslund(t) wrote:

> > You can use distributed revision control systems as centralized
> > systems, but not vice-versa.
> >
>
> Not true, the other way around exists, that is what svk does.

From its description, svk sounds like a completely different system:

``svk is a decentralized version control system written in Perl. It
uses the subversion filesystem but provides some other powerful
features.''

I.e. it seems to have a CVS vs. RCS relationship. It would be unfair
to call CVS RCS.

--
Dustin Sallings

<quote who="Dustin Sallings">
>
> On Mar 25, 2004, at 1:21, Neil Conway wrote:
>
>> I think the lack of good Win32 support (unless rectified before the
>> release of 7.5) is a pretty major problem with Arch -- that alone
>> might be sufficient to prevent us from adopting it.
>
> I don't do Windows, but my understanding is that tla is as well
> supported on Windows as postgres is.
>

It that like the best beach volleball player in Antarctica? The Windows
port of Postgresql is still in its infancy. It's coming along, but its
not a finished product.

> The design is fundamentally easy enough that a Windows user who cares
> could probably make a more suitable port for Windows than the UNIX guys
> are interested in making. I've seen such discussions on the list.
>
> --
> Dustin Sallings
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

On 25-Mar-04, at 3:03 PM, Dustin Sallings wrote:
> I don't do Windows, but my understanding is that tla is as well
> supported on Windows as postgres is.

David Wheeler disagrees:

A serious weakness of arch is that it doesn't work well on
Windows-based systems, and it's not clear if that will ever change.
There are ports of arch, both non-native (Cygwin and Services for Unix)
and a native port too. However, the current win32 port is only in its
early stages, and the Win32 page on the Arch wiki says "Arch was never
intended to run on a non-POSIX system. Don't expect to have a full
blown arch on your Microsoft computer." At least part of the problem is
the long filenames used internally by arch; arch could certainly be
modified to help, though there doesn't seem to be much movement in that
direction. Other problematic areas include symbolic links, proper file
permissions, and newline problems, as well as the general immaturity of
the port as of March 2004. Some people don't think that poor Windows
support is a problem; to me (and others!), that's a serious problem.
Even if you don't use any Microsoft Windows systems, people don't want
to use many different SCM systems, so if one can handle many
environments and the other can't, people will use the one that can
handle more environments. I think GNU Arch's use will be hampered by
this lack of support as long as this is true, even for people who never
use Windows; good native Windows support is very important for an SCM
tool.

-Neil

(To resurrect an old thread, I've finally got some time to devote to
this; I'll post a patch once I've got something ready for public
consumption.)

On 23-Mar-04, at 4:59 PM, Tom Lane wrote:
> Let's see ... fleshing out this idea a bit, here's a rundown of all the
> symbols in pg_list.h and suggested new names: [...]

Most of your suggestions are agreeable; a few minor quibbles follow.

> lfirstcell new function to get first cell, or NULL if none
[...]
> llastnode llastcell

What do you think of list_head() and list_tail() instead?

> set_union list_union
> set_ptrUnion list_union_ptr
> list_union_int not currently used
> set_uniono list_union_oid

I don't see the need for anything more than set_difference() and
set_difference_ptr() -- if we're passed a T_IntList or a T_OidList, we
can examine the list tag and do the Right Thing automagically. ISTM we
only need the xxx_int() and xxx_oid() variants when something in the
function's signature depends on the type of the list's elements.

> set_difference list_difference
> set_ptrDifference list_difference_ptr
> list_difference_int not currently used
> set_differenceo list_difference_oid

Ibid.

-Neil

Neil Conway <neilc(at)samurai(dot)com> writes:
> Most of your suggestions are agreeable; a few minor quibbles follow.

>> lfirstcell new function to get first cell, or NULL if none
> [...]
>> llastnode llastcell

> What do you think of list_head() and list_tail() instead?

No strong objection, though I thought it was a good idea to include
"cell" in the function names to suggest that what you are getting back
is just a cell and not a List. Anyone else have a preference?

>> set_union list_union
>> set_ptrUnion list_union_ptr
>> list_union_int not currently used
>> set_uniono list_union_oid

> I don't see the need for anything more than set_difference() and
> set_difference_ptr() -- if we're passed a T_IntList or a T_OidList, we
> can examine the list tag and do the Right Thing automagically.

Well, we could, but AFAIK there are no situations where the caller
doesn't know exactly what he wants, and so a switch in the function body
is just a waste of cycles. It is probable that these functions are slow
enough and seldom-used enough that the extra switch doesn't matter much,
so that argument may not have much force. I guess the real question in
my mind is whether there is any true gain in symmetry or readability by
doing it this way. The other functions such as the cons family *will*
need to have the three variants, and so I question that it makes sense
to make these different. Also the need for the _ptr variant makes it a
bit asymmetric even just when looking at these functions.

regards, tom lane

Tom Lane wrote:
> Neil Conway <neilc(at)samurai(dot)com> writes:
> > Most of your suggestions are agreeable; a few minor quibbles follow.
>
> >> lfirstcell new function to get first cell, or NULL if none
> > [...]
> >> llastnode llastcell
>
> > What do you think of list_head() and list_tail() instead?
>
> No strong objection, though I thought it was a good idea to include
> "cell" in the function names to suggest that what you are getting back
> is just a cell and not a List. Anyone else have a preference?

I never liked "cell" myself. It is too vague to me. But I see your
point that list_head you would think returns the head of the list, not
the first element in the list. Maybe list_first and list_last?

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On 28-Apr-04, at 12:12 AM, Bruce Momjian wrote:
> I never liked "cell" myself. It is too vague to me. But I see your
> point that list_head you would think returns the head of the list, not
> the first element in the list.

I'm not sure what you mean: list_head() returns the "head of the list",
which is the first cell in the list. That cell contains a data value
and a pointer to the next cell in the list. Makes sense to me...

-Neil

On 27-Apr-04, at 10:07 PM, Tom Lane wrote:
[ ... on the topic of list_union(), list_union_int() and friends ]
> I guess the real question in my mind is whether there is any true gain
> in symmetry or readability by doing it this way.

I think there's a small gain: everything else being equal, an API with
fewer functions is easier to use and easier to understand. If we can
provide a single function that takes the place of three functions
without losing anything, we ought to do so.

-Neil

Neil Conway wrote:
> On 28-Apr-04, at 12:12 AM, Bruce Momjian wrote:
> > I never liked "cell" myself. It is too vague to me. But I see your
> > point that list_head you would think returns the head of the list, not
> > the first element in the list.
>
> I'm not sure what you mean: list_head() returns the "head of the list",
> which is the first cell in the list. That cell contains a data value
> and a pointer to the next cell in the list. Makes sense to me...

Oh, I thought cell returned the first data value, not the
first-data-and-pointer-to-next-one. Yes, list_head and list_tail seems
fine. Why mix "cell" in there? I don't know what a cell is.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073