Re: embedded list

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: embedded list
Date: 2012-10-18 20:56:07
Message-ID: 4957.1350593767@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> Oops. I mentioned this explicitely somewhere in the discussion. I
> assumed you had seen that, and that you would have complained had you
> found it objectionable.

Sorry, I've been too busy to pay very much attention to this patch.

>> I think we should remove the head argument at least from dlist_delete,
>> and probably also dlist_insert_after and dlist_insert_before.

> There are more functions that get the list head just to run the check.
> Can I assume that you don't propose removing the argument from those?
> (dlist_next_node, dlist_prev_node I think are the only ones).

Yeah, I wondered whether to do the same for those. But it's less of an
issue there, because in practice the caller is almost certainly going to
also need to do dlist_has_next or dlist_has_prev respectively, and those
require the list header.

On the other hand, applying the same principle to slists, you could
argue that slist_has_next and slist_next_node should not require the
head pointer (since that's throwing away an advantage of slists).
If we wanted to remove the head pointer from those, there would be some
value in not having the head argument in dlist_next_node/dlist_prev_node
for symmetry with slist_next_node.

I'm not as excited about these since it seems relatively less likely to
matter. What do you think?

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Любен Каравелов 2012-10-18 21:58:42 Re: Deprecating RULES
Previous Message Andrew Dunstan 2012-10-18 20:55:02 Re: Deprecating RULES