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.