Re: Add new for_each macros for iterating over a List that do not require ListCell pointer

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: vignesh C <vignesh21(at)gmail(dot)com>
Cc: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add new for_each macros for iterating over a List that do not require ListCell pointer
Date: 2023-12-21 03:25:19
Message-ID: 20231221032519.GA836535@nathanxps13
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 20, 2023 at 12:21:05PM +0530, vignesh C wrote:
> On Tue, 19 Dec 2023 at 21:22, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>> I'm not sure we should proceed with rewriting most/all eligible foreach
>> loops. I think it's fine to use the new macros in new code or to update
>> existing loops in passing when changing nearby code, but rewriting
>> everything likely just introduces back-patching pain in return for little
>> discernible gain.
>
> +1 for this. Let's just provide the for_each macros to be used for new code.
> This means that the
> 0003-Use-new-foreach_xyz-macros-in-a-few-places.patch will not be
> present in the final patch right?

It might be worth changing at least one of each type to make sure the
macros compile, but yes, I don't think we need to proceed with any sort of
bulk changes of existing loops for now.

BTW I think v7-0001 and v7-0002 are in pretty good shape. I'm going to
mark this as ready-for-committer and see if I can get those two committed
sooner than later.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2023-12-21 04:00:01 Re: trying again to get incremental backup
Previous Message Michael Paquier 2023-12-21 03:17:27 Re: Function to get invalidation cause of a replication slot.