Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Mon, 28 Sep 2020 at 15:35, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Poking around to count remaining uses of those inline functions,
>> I found a few places that should be using the macros instead,
>> and fixed them. After that, I notice that list_tail(),
>> list_third_cell(), and list_fourth_cell() are entirely unreferenced.
>> I'm hesitant to get rid of list_tail(), because it seems like it
>> could well be used by extensions. But I'd bet quite a bit that
>> list_third_cell() and list_fourth_cell() are not used anywhere
>> anymore. Should we get rid of them to shave a few microseconds
>> from compile times?

> I wouldn't object to the removal of list_third_cell() and list_fourth_cell().

> I agree to your reasoning with last_tail(). It does seem more likely
> that someone would use it. Although, if you'd proposed to remove it
> too, I wouldn't have objected. It's not like it's hard to reimplement
> within an extension for any extensions that use it. Though, perhaps it
> would maybe be a shame if that was the sole thing we broke for them
> when they try compiling their extension in a year's time on the newly
> release PG14.

Looking a bit harder, I notice that list_third_cell() and
list_fourth_cell() were in fact introduced in v13, purely to support
lthird() and lfourth(). So it hardly seems likely that any extensions
would have grown direct dependencies on them already. list_tail()
has been there a long time though.

Just to be sure, I checked codesearch.debian.net, and it failed
to find any outside uses either. So I'll go ahead and remove
those two.

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.

regards, tom lane