Currently, the recursion in ExplainNode() goes to some lengths to chase down the PlanState and Plan trees independently. This is a bit silly: we could just chase the PlanState tree, and use each PlanState's "plan" link when we needed to get to the matching Plan node. I think this is a holdover from long ago when the code worked only with Plan trees --- the PlanState stuff was bolted on rather than replacing that logic entirely. But there is no capacity for EXPLAINing a Plan tree without having constructed a PlanState tree, and I don't foresee that we'd add one (for one reason, EXPLAIN depends on ExecutorStart to perform permissions checking for the referenced tables). Any objections to getting rid of the separate Plan argument?
The reason I'm on about this at the moment is that I think I see how to get ruleutils to print PARAM_EXEC Params as the referenced expression rather than $N ... but it depends on having the PlanState tree at hand. So fixing that will destroy any last shred of credibility there might be for EXPLAINing a Plan tree without PlanState. In fact I'm thinking I need to change deparse_context_for_plan() to take a PlanState not a Plan. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers