Re: read-only planner input

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