Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> Tom> The second of those; what we need is for any referenced InitPlans
> Tom> to be executed afresh under EPQ rules. (I'm not entirely sure that
> Tom> an InitPlan could need to see different input tuples under EPQ
> Tom> than it'd see otherwise, but I'm not sure it couldn't, either.)
> Shouldn't the InitPlan pretty much by definition be independent of the
> tuples being locked/updated?
[ thinks for awhile... ] Yeah, I wasn't thinking clearly enough. The
point of the special EPQ rules is that, other than the target row-being-
updated, any tuples from other tables should be the *same* tuples we'd
joined that row to before EPQ. The logical extension of that to InitPlans
is that it should be the same InitPlan output as before, not potentially
a different value ...
> And doesn't executing them again run the risk of getting a different
> value for other reasons, for example if an initplan is volatile?
... and that's another good argument for not doing the initplan over.
> What I'm wondering is whether the param in the copied estate shouldn't
> rather be just a proxy for the one in the original estate - if we need
> to evaluate it, then do so in the original estate, store the value
> there, and copy the value back into the EPQ plantree.
Don't think that's going to work; the EPQ environment doesn't have any way
to know that an execPlan link is pointing to something in a different
estate.
Your other idea of forcing initPlan parameters to be evaluated before we
enter the EPQ execution environment is probably more workable. It would
be annoying to do that for every initPlan in sight, but I think we could
look at the subplan's extParam to see whether it potentially references
that parameter. (Although really, in most scenarios it wouldn't matter
because all the initPlans in a data-modifying query are probably
referenced in the subplan anyhow ...)
regards, tom lane