Thread: 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@postgresql.org/msg02204.html http://www.mail-archive.com/pgsql-patches@postgresql.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
On Tue, 23 Mar 2004 08:39:21 -0800 Sailesh Krishnamurthy <sailesh@cs.berkeley.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 beenusing it for awhile now on my little projects and it's a joy to work with. --------------------------------- Frank Wiles <frank@wiles.org> http://frank.wiles.org---------------------------------
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
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@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
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@spy.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@dcc.uchile.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@candle.pha.pa.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@candle.pha.pa.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@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
Bruce Momjian <pgman@candle.pha.pa.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@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
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.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 bythe 'n' which signalsa 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@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
Bruce Momjian <pgman@candle.pha.pa.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@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
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@hub.org Yahoo!: yscrappy ICQ: 7615664
Neil Conway <neilc@samurai.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@postgresql.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 giveus 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@samurai.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@samurai.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 functionscan be candidates for rename. I read Mono docs last night andit'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 totarget and forgot that with code work others people and not CPU only.(sorry of this pontification:-) Karel -- Karel Zak <zakkr@zf.jcu.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@spy.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 Tue, 23 Mar 2004 23:03:03 -0400 (AST) "Marc G. Fournier" <scrappy@postgresql.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 Ican 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 taggingare 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 goesfor 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 transferthat 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 everyoneknows 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 copyare essentially doubled. There is a copy in your .svn directory that allows the offline status, diff, and revert commandsto work. --------------------------------- Frank Wiles <frank@wiles.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
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) itselfis 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@spy.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@zeut.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@spy.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@Yahoo.com #
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
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"
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 ityourself), a really> good presentation was posted today to the arch list that sums it up> quickly and concisely. It'shard 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
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
<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@postgresql.org) >
After a long battle with technology, scrappy@postgresql.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
(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@samurai.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@samurai.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@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
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@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