Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros - Mailing list pgsql-hackers

From David Rowley
Subject Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros
Date
Msg-id CAApHDvrn=7wJ9Khb-6DdhZBv_gqre4kvymJYnZdd+Mfcok+E8g@mail.gmail.com
Whole thread Raw
In response to Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Thanks for 9d299a492.

On Mon, 28 Sep 2020 at 15:35, Tom Lane <tgl@sss.pgh.pa.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.

David



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Next
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist