On 30.05.2011 17:21, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> I think we can work around both of those by just saving and restoring
>> the value of each Param that we set while evaluating an expression,
>
> Huh? That's a waste of time and effort. Just make sure that each such
> spot has its own Param number. That's why I'm telling you to do it in
> the planner, not the parser --- it is easy to assign globally-unique-
> across-the-plan numbers at plan time, in fact we do it already.
Yeah, I got that part. What I'm saying is that it's not that easy,
because of the two issues, domain constraints and index expressions,
that I mentioned. Here's a WIP patch, but those two issues have not been
addressed yet. I'm sure those are not insurmountable problems, I'm just
trying to figure out the best way to surmount them:
For domain constraints, ExecInitExpr could assign globally-unique param
numbers if it knew how many params are in use. That's trivial for
expressions in plans, as you have access to the EState via the
PlanState, and EState can include the number of params assigned. For a
stand-alone expression, we don't have that. There is no global
information whatsoever for stand-alone expressions, ExecInitExpr only
sees the current node it's dealing with. Perhaps we need to add the
concept of a global plan
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com