Re: [HACKERS] explain.c: why trace PlanState and Plan trees separately?

2010-07-13 Thread Yeb Havinga
Tom Lane wrote: Yeb Havinga writes: Tom Lane wrote: 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 ... Wouldn't this obfuscate the plan more than printing subplan argume

Re: [HACKERS] explain.c: why trace PlanState and Plan trees separately?

2010-07-13 Thread Tom Lane
Yeb Havinga writes: > Tom Lane wrote: >> 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 ... > Wouldn't this obfuscate the plan more than printing subplan arguments at > the call si

Re: [HACKERS] explain.c: why trace PlanState and Plan trees separately?

2010-07-13 Thread Yeb Havinga
Tom Lane wrote: 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 ... Wouldn't this obfuscate the plan more than printing subplan arguments at the call site? regards, Yeb Havinga -- Sen

[HACKERS] explain.c: why trace PlanState and Plan trees separately?

2010-07-12 Thread Tom Lane
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 fr