Re: Oddity in tuple routing for foreign partitions

On 2018/04/17 16:41, Etsuro Fujita wrote:
> In the INSERT/COPY-tuple-routing case, as explained by Amit, the
> RTE at that position in the EState's range table is the one for the
> partitioned table of a given partition, so the statement would be true. 
> BUT in the UPDATE-tuple-routing case, the RTE is the one for the given
> partition, not for the partitioned table, so the statement would not be
> true.  In the latter case, we don't need to create a child RTE and replace
> the original RTE with it, but I handled both cases the same way for
> simplicity.

Oh, I didn't really consider this part carefully.  That the resultRelInfo
received by BeginForeignInsert (when called by ExecInitRoutingInfo) could
be a reused UPDATE result relation.  It might be possible to justify the
parent_rte/child_rte terminology by explaining it a bit better.  I see
three cases that arise during tuple routing:

1. This is INSERT and so the resultRelation that's received in
   BeginForeignInsert has been freshly created in ExecInitPartitionInfo
   and it bears node->nominalRelation or 1 as its ri_RangeTableIndex

2. This is UPDATE and the resultRelInfo that's received in
   BeginForeignInsert has been freshly created in ExecInitPartitionInfo
   and it bears node->nominalRelation or 1 as its ri_RangeTableIndex

3. This is UPDATE and the resultRelInfo that's received in
   BeginForeignInsert is a reused one, in which case, it bears the planner
   assigned ri_RangeTableIndex

In all three cases, I think we can rely on using ri_RangeTableIndex to
fetch a valid "parent" RTE from es_range_table.

Do you think we need to clarify this in a comment?

Thanks,
Amit