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

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Jelte Fennema <postgres(at)jeltef(dot)nl>
Cc: Nathan Bossart <nathandbossart(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-10-25 02:55:22
Message-ID: CAApHDvoHsA4B5MKC5RXw8z+_7jM39zXOLr1S0jVit_gx0BxKDQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 25 Oct 2023 at 06:00, Jelte Fennema <postgres(at)jeltef(dot)nl> wrote:
> Attached is a fixed version.

With foreach(), we commonly do "if (lc == NULL)" at the end of loops
as a way of checking if we did "break" to terminate the loop early.
Doing the equivalent with the new macros won't be safe as the list
element's value we broke on may be set to NULL. I think it might be a
good idea to document the fact that this wouldn't be safe with the new
macros, or better yet, document the correct way to determine if we
broke out the loop early. I imagine someone will want to do some
conversion work at some future date and it would be good if we could
avoid introducing bugs during that process.

I wonder if we should even bother setting the variable to NULL at the
end of the loop. It feels like someone might just end up mistakenly
checking for NULLs even if we document that it's not safe. If we left
the variable pointing to the last list element then the user of the
macro is more likely to notice their broken code. It'd also save a bit
of instruction space.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shveta malik 2023-10-25 03:00:59 Re: Synchronizing slots from primary to standby
Previous Message Tatsuo Ishii 2023-10-25 02:49:30 Re: Row pattern recognition