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
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. |