On 31.05.2011 19:10, Heikki Linnakangas wrote:
> For index expressions, we could use a function similar to
> ChangeVarNodes(), that shifts all the paramids in the already-planned
> expression, preparing it for inclusion within the enclosing plan. I'm a
> bit worried that that might screw up the logic used to compare if an
> expression matches the index expression, though; the param ids in the
> two expressions won't match.
Yeah, the expression comparison logic gets all confused by this :-(. I
couldn't figure out a way to make it work without making the comparison
a whole lot more complicated than it is today. I'm going back to my
original thoughts of a new kind of node to replace CaseTestExpr, which
allows referencing values from upper levels in the expression tree.
So, here's a WIP patch using that approach. I've replaced CaseTestExpr
with ExpressionParam. ExpressionParam has a levelsup field, which is
similar to varlevelsup in Var. With levelsup == 0, ExpressionParam works
just like CaseTestExpr did. With levelsup == 1, it refers to the value
from above the enclosing CaseExpr (or any other node that uses these
ExpressionParams/CaseTestExprs).
The complicated part is to ensure that levelsup is always set correctly.
At parse time, levelsup is always set to 0, as the syntax doesn't allow
referencing upper levels directly. When an SQL function is inlined, any
ExpressionParams in the expressions that are substituted for Params need
to have their levelsup adjusted, so that it still refers to the right
value if there's CASE expressions in the inlined function. Also, when an
ExpressionParam is replaced with a Const, the levelsup fields of any
other ExpressionParams within the CaseExpr referring to higher levels
need to have their levelsup decremented to account for the fact that the
CaseExpr doesn't push the expression parameter anymore.
At execution time, the expression parameters form a stack. We've always
done the save-restore logic, but the stack is now represented explicitly
as a List in ExprContext. When an ExpressionParam is evaluated, the nth
element is fetched from the stack, corresponding to levelsup.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
