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

From: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: vignesh C <vignesh21(at)gmail(dot)com>, 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-19 16:47:42
Message-ID: CAGECzQSY8hYSEuJzUa8m1hW-cTAxeAhvo1JRFTRe3WeumiHnag@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 19 Dec 2023 at 16:52, 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.

To clarify: I totally agree that if we're not backpatching this we
shouldn't do bulk changes on existing loops to avoid pain when
backpatching other patches.

> Unless there's some way to argue this is a bug, security issue, or data
> corruption problem [0], I seriously doubt we will back-patch this.

In the past some tooling changes have been backpatched, e.g.
isolationtester has received various updates over the years (I know
because this broke Citus its isolationtester tests a few times because
the output files changed slightly). In some sense this patch could be
considered tooling too. Again: not saying we should back-patch this,
but we could only realistically bulk update loops if we do.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tristan Partin 2023-12-19 16:54:36 Re: Add --check option to pgindent
Previous Message Nathan Bossart 2023-12-19 16:44:52 Re: add non-option reordering to in-tree getopt_long