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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Small improvements to pg_list.h's linitial(), lsecond(), lthird() etc macros
Date: 2020-09-28 02:47:22
Message-ID: CAApHDvrn=7wJ9Khb-6DdhZBv_gqre4kvymJYnZdd+Mfcok+E8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thanks for 9d299a492.

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.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message tsunakawa.takay@fujitsu.com 2020-09-28 02:50:20 RE: [Patch] Optimize dropping of relation buffers using dlist
Previous Message Amit Kapila 2020-09-28 02:46:16 Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables