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