On 2014/12/23 0:36, Tom Lane wrote:
> Yeah, we need to do something about the PlanRowMark data structure.
> Aside from the pre-existing issue in postgres_fdw, we need to fix it
> to support inheritance trees in which more than one rowmark method
> is being used. That rte.hasForeignChildren thing is a crock, and
> would still be a crock even if it were correctly documented as being
> a planner temporary variable (rather than the current implication that
> it's always valid). RangeTblEntry is no place for planner temporaries.
Agreed.
> The idea I'd had about that was to convert the markType field into a
> bitmask, so that a parent node's markType could represent the logical
> OR of the rowmark methods being used by all its children. I've not
> attempted to code this up though, and probably won't get to it until
> after Christmas. One thing that's not clear is what should happen
> with ExecRowMark.
That seems like a good idea, as parent PlanRowMarks are ignored at runtime.
Aside from the above, I noticed that the patch has a bug in handling
ExecRowMarks/ExecAuxRowMarks for foreign tables in inheritance trees
during the EPQ processing.:-( Attached is an updated version of the
patch to fix that, which has been created on top of [1], as said before.
Thanks,
[1] http://www.postgresql.org/message-id/5497BF4C.6080302@lab.ntt.co.jp
Best regards,
Etsuro Fujita