Greg Stark <st...@mit.edu> writes: > I do note that the code in question was added in this commit in 2010. > That predates the addition of LATERAL in 2013.
Yeah. It's pretty clear from the comments that I was concerned about false matches of PARAM_EXEC numbers. I think that was a live issue at the time but is so no longer, cf. 46c508fbc and 1db5667ba. The possibility of LATERAL references is what makes it interesting to search higher in the plan tree, so there wasn't any real reason to take any risk of a false match. I think I might've also been concerned about printing misleading names for any Vars we did find, due to them belonging to a different query level. That's probably a dead issue too now that ruleutils assigns unique aliases to all RTEs in the query (I'm not sure if it did at the time). Looking at this now, it seems a little weird to me that we allow LATERAL values to be passed down directly into the subplan rather than having them go through the parParam mechanism. (If they did, ruleutils' restriction would be fine.) I don't know of a reason to change that, though. > I suppose those > comments may be talking about InitPlans for things like constant > subqueries that have been pulled up to InitPlans in queries like: > explain verbose select * from x join y on (x.i=y.j) where y.j+1=(select 5) ; > Which your patch doesn't eliminate the $0 in. No, because that $0 is for a subplan/initplan output, which we don't have any other sort of name for. Your example produces output that explains what it is: InitPlan 1 (returns $0) ... Filter: ((y.j + 1) = $0) although I'm not sure that we document that anywhere user-facing. > Fwiw your patch applied for me and built without warnings and seems to > work for all the queries I've thrown at it so far. That's hardly an > exhaustive test of course. I'm content to apply this (although I quibble with removal of some of the commentary). Worst case, somebody will find an example where it produces wrong/misleading output, and we can revert it. But the regression test changes show that it does produce useful output in at least some cases. regards, tom lane