Tom Lane wrote:
> That's a bit nasty. I'm fairly sure that I added in_info_list to the
> walker recursion because I had to; I don't recall the exact scenario,
> but I think it needs to be possible to reassign relation numbers
> within that data structure if we are doing it elsewhere in a query
> tree.
It was r1.125 of clauses.c, and yes, it seems pretty important. It's
used in adjust_inherited_attrs_mutator() in prep/prepunion.c,
flatten_join_alias_vars_mutator() in util/var.c, and three different
walkers in rewriteManip.c. That's from trawling through the original
(Jan of '03) patch -- it may have been used elsewhere subsequently.
Here's one idea to fix this: when planning a Query, transform the Query
into a "PlannedQuery". This would essentially be the same as the
QueryState we discussed earlier, except that we would also walk through
the Query and adjust references to nested Queries to refer to
PlannedQueries instead (so RTEs for subqueries would reference the
PlannedQuery, not the Query, for example). There would then be a
"planned query walker" that would walk both the original query and
additional planner-specific working state, and so on.
Perhaps we could use some trickery to avoid the PlannedQuery vs. Query
distinction when a particular piece of code doesn't care, by making
Query the first field of PlannedQuery. In other words:
struct PlannedQuery { Query q; /* other fields */
};
So we could treat a PlannedQuery * like a Query *. I don't really like
this solution.
Another possibility would be to punt, and keep in_info_list as part of
Query. We'd then need to resolve modifications to it in the same we way
will need to resolve modifications to legitimate parts of the Query
(e.g. by making an initial shallow copy and avoiding destructive
updates, per earlier discussion).
-Neil
