Tom Lane wrote:
> I'd go with PlannerState. QueryState for some reason sounds more like
> execution-time state.
Well, not to me :) It just makes sense to me that QueryState as the
working state associated with a Query. Not sure it makes a big
difference, though.
> Pulling the "planner internal" stuff out of the Query node does seem
> like a good idea, even so.
I've got most of this finished; I'll post a patch soon. One issue I ran
into is how to handle query_tree_mutator() and query_tree_walker(): they
both expect to be able to traverse a Query's in_info_list, which my
patch moves into the QueryState struct. If maintaining this property is
essential, it seems that we'll need a way to get the QueryState
associated with a given Query. We can't just change the query tree
walker to be a "query state walker", since we need to be able to recurse
into subqueries, and the RTE for a subquery will only contain a Query,
not its QueryState. Any thoughts on the best way to fix this?
-Neil
