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
---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
