Re: Replace remaining castNode(…, lfirst(…)) and friends calls with l*_node()

On 08.07.21 20:17, Alvaro Herrera wrote:
>> diff --git a/src/backend/rewrite/rewriteSearchCycle.c b/src/backend/rewrite/rewriteSearchCycle.c
>> index 599fe8e735..c50ebdba24 100644
>> --- a/src/backend/rewrite/rewriteSearchCycle.c
>> +++ b/src/backend/rewrite/rewriteSearchCycle.c
>> @@ -307,8 +307,8 @@ rewriteSearchAndCycle(CommonTableExpr *cte)
>> list_nth_oid(cte->ctecolcollations, i),
>> 0);
>> tle = makeTargetEntry((Expr *) var, i + 1, strVal(list_nth(cte->ctecolnames, i)), false);
>> - tle->resorigtbl = castNode(TargetEntry, list_nth(rte1->subquery->targetList, i))->resorigtbl;
>> - tle->resorigcol = castNode(TargetEntry, list_nth(rte1->subquery->targetList, i))->resorigcol;
>> + tle->resorigtbl = list_nth_node(TargetEntry, rte1->subquery->targetList, i)->resorigtbl;
>> + tle->resorigcol = list_nth_node(TargetEntry, rte1->subquery->targetList, i)->resorigcol;
> This seems a bit surprising to me. I mean, clearly we trust our List
> implementation to be so good that we can just fetch the same node twice,
> one for each member of the same struct, and the compiler will optimize
> everything so that it's a single access to the n'th list entry. Is this
> true? I would have expected there to be a single fetch of the struct,
> followed by an access of each of the two struct members.

Lists are arrays now internally, so accessing an element by number is
pretty cheap.