Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros
От | David Rowley |
---|---|
Тема | Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros |
Дата | |
Msg-id | CAApHDvoKf1yM_7DV0jPmWbkuhuhNUGVEBSr+Ou-jLmnDeYA80g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros
|
Список | pgsql-hackers |
On Tue, 29 Sep 2020 at 11:37, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > I wrote: > > list_second_cell() does have uses, although I observe that they > > are almost exclusively in locutions such as > > for_each_cell(lc, rollups, list_second_cell(rollups)) > > to iterate over all-but-the-first elements of a list. I wonder if > > we ought to come up with a better notation for that. I'm imagining > > something like > > for_each_from(lc, rollups, 1) > > to start from list index 1. It looks like this would be marginally > > more efficient, and perhaps more readable. > > 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(). > 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. David
В списке pgsql-hackers по дате отправления: