Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Feb 27, 2019 at 3:27 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 0001 below does this. I found a couple of places that could use
>> forfive(), as well. I think this is a clear legibility and
>> error-proofing win, and we should just push it.
> It sounds like some of these places might need a bigger restructuring
> - i.e. to iterate over a list/vector of structs with 5 members instead
> of iterating over five lists in parallel.
Meh. Most of them are iterating over parsetree substructure, eg the
components of a RowCompareExpr. So we could not change them without
pretty extensive infrastructure changes including a catversion bump.
Also, while the separated substructure is indeed a pain in the rear
in some places, it's actually better for other uses. Two examples
related to RowCompareExpr:
* match_rowcompare_to_indexcol can check whether all the left-hand
or right-hand expressions are nonvolatile with one easy call to
contain_volatile_functions on the respective list. To do the
same with a single list of sub-structs, it'd need bespoke code
for each case to run through the list and consider only the correct
subexpression of each sub-struct.
* expand_indexqual_rowcompare can deal with commuted-clause cases just
by swapping the list pointers at the start, it doesn't have to think
about it over again for each pair of elements.
So I'm not that excited about refactoring the data representation
for these. I'm content (for now) with getting these places in line
with the coding convention we use elsewhere for similar cases.
regards, tom lane