Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros
От | Tom Lane |
---|---|
Тема | Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros |
Дата | |
Msg-id | 477797.1601336574@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros (David Rowley <dgrowleyml@gmail.com>) |
Ответы |
Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros
|
Список | pgsql-hackers |
David Rowley <dgrowleyml@gmail.com> writes: > On Tue, 29 Sep 2020 at 11:37, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Concretely, I'm thinking about the attached. > I had a look over this and I like it. It seems good as it allows > consumers to choose N programmatically rather than be fixed into using > list_second_cell() or list_fortysecond_cell(). Thanks for looking! Right now, if you want to start from a non-first point in the list, you have to use for_each_cell (or else write out a loop manually, but let's not). I'm not proposing to remove that alternative, but there are surely cases where it's simpler or clearer to use a list index instead of a ListCell pointer -- especially so if the list index is a constant. So I think this is a pretty clear win that simply failed to occur to me earlier. >> I'm somewhat inclined to back-patch this into v13. The missing >> const decoration seems arguably a bug, which we've missed noticing >> only because of our generally lamentable under-usage of const. >> And I think it'll be helpful for future back-patching if >> for_each_from is available in all versions with the new List API. > It does seem fairly low risk and having personally experienced > backpatching pain, I understand your motivation to backpatch. I > certainly wouldn't object to backpacking but will defer to your better > judgement on whether you choose to or not. A key point here is that everyplace I'm proposing to touch was already changed in v13 (a fortiori, because list_second_cell wasn't there in v12). So we can either have two different coding patterns in these areas, or three. Two's better from a backpatching standpoint. The fact that v13 is barely out the door also factors into this ... a year from now, my judgment would probably be different. regards, tom lane
В списке pgsql-hackers по дате отправления: