Re: embedded list

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: embedded list
Дата
Msg-id 4957.1350593767@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: embedded list  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Deprecating RULES
Следующее
От: Любен Каравелов
Дата:
Сообщение: Re: Deprecating RULES