From: | Jelte Fennema <postgres(at)jeltef(dot)nl> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | 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 12:35:45 |
Message-ID: | CAGECzQTn-teFSHNu0en0D8kr9QohqQN9ebiNeTjXencn+uRXgg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 25 Oct 2023 at 13:52, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Looking at for_each_ptr() I think it may be cleaner to follow
> palloc_object()'s precedent and make it foreach_object() instead (I have
> no love for the extra underscore, but I won't object to it either). And
> like foreach_node, have it receive a type name to add a cast to.
>
> I'd imagine something like
>
> SubscriptionRelState *rstate;
>
> foreach_object(SubscriptionRelState *, rstate, table_states_not_ready)
> {
Could you clarify why you think it may be cleaner? I don't see much
benefit to passing the type in there if all we use it for is adding a
cast. It seems like extra things to type for little benefit.
palloc_object uses the passed in type to not only do the cast, but
also to determine the size of the the allocation.
If foreach_object would allow us to remove the declaration further up
in the function I do see a benefit though.
I attached a new patchset which includes a 3rd patch that does this
(the other patches are equivalent to v4). I quite like that it moves
the type declaration to the loop itself, limiting its scope. But I'm
not fully convinced it's worth the hackiness of introducing a second
for loop that does a single iteration, just to be able to declare a
variable of a different type though. But I don't know another way of
achieving this. If this hack/trick is deemed acceptable, we can do the
same for the other newly introduced macros. The type would not even
need to be specified for oid/xid/int because it's already known to be
Oid/TransactionId/int respectively.
Attachment | Content-Type | Size |
---|---|---|
v5-0001-Add-macros-for-looping-through-a-list-without-nee.patch | application/octet-stream | 6.0 KB |
v5-0003-Introduce-for_each_object.patch | application/octet-stream | 2.7 KB |
v5-0002-Use-new-for_each_xyz-macros-in-a-few-places.patch | application/octet-stream | 7.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Dilip Kumar | 2023-10-25 12:43:27 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Previous Message | Amit Kapila | 2023-10-25 12:28:09 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |