]> granicus.if.org Git - postgresql/commit
Standardize some more loops that chase down parallel lists.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 28 Feb 2019 19:25:01 +0000 (14:25 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 28 Feb 2019 19:25:01 +0000 (14:25 -0500)
commitc94fb8e8acc05c4b5f9f5b2a595ce7930827c2be
treeaafacc4fb6291f41aeb9eeb15234fbac83c83e90
parent0a271df705c98c1cc617078ebd069cf080fa5a16
Standardize some more loops that chase down parallel lists.

We have forboth() and forthree() macros that simplify iterating
through several parallel lists, but not everyplace that could
reasonably use those was doing so.  Also invent forfour() and
forfive() macros to do the same for four or five parallel lists,
and use those where applicable.

The immediate motivation for doing this is to reduce the number
of ad-hoc lnext() calls, to reduce the footprint of a WIP patch.
However, it seems like good cleanup and error-proofing anyway;
the places that were combining forthree() with a manually iterated
loop seem particularly illegible and bug-prone.

There was some speculation about restructuring related parsetree
representations to reduce the need for parallel list chasing of
this sort.  Perhaps that's a win, or perhaps not, but in any case
it would be considerably more invasive than this patch; and it's
not particularly related to my immediate goal of improving the
List infrastructure.  So I'll leave that question for another day.

Patch by me; thanks to David Rowley for review.

Discussion: https://postgr.es/m/11587.1550975080@sss.pgh.pa.us
src/backend/access/common/tupdesc.c
src/backend/executor/execExpr.c
src/backend/executor/nodeIndexscan.c
src/backend/optimizer/plan/subselect.c
src/backend/optimizer/prep/prepunion.c
src/backend/parser/analyze.c
src/backend/parser/parse_func.c
src/backend/utils/adt/ruleutils.c
src/include/nodes/pg_list.h