On 2018/04/26 2:59, Robert Haas wrote:
> On Tue, Apr 24, 2018 at 10:19 PM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> I tried to do that. So, attached are two patches.
>>
>> 1. Fix for ExecInitPartitionInfo to use the right RT index to pass to
>> InitResultRelInfo
>>
>> 2. v5 of the patch to fix the bug of foreign partitions
>>
>> Thoughts?
>
> Are you splitting this into 2 patches here because there are 2
> separate issues? If so, what are those issues? There seem to be a
> bunch of interrelated changes here but I haven't seen a clear
> explanation of which ones are needed for which reasons.
>
> I agree that fixing ExecInitPartitionInfo to use the right RT index in
> the first place sounds like a better idea than trying to piece
> together which RT index we should be using after-the-fact, but I need
> to better understand what problems we're trying to fix here before I
> can be sure if that's the strategy I want to endorse...
After considering Fujita-san's comment downthread, I think it might be
better to revisit 1 later, because it could break a certain things which
rely on ri_RangeTableIndex being set to the index of the root partitioned
table's RT entry. Fujita-san pointed out GetInsertedColumns et al that
return a set of attribute numbers after looking up the RT entry using
ri_RangeTableIndex of a given ResultRelInfo. They would start returning a
different set for partitions than previously in some cases due to this
change. Maybe, there are other things that rely on what a partition's
ri_RangeTableEntry has been set to.
For now, I think we'll have to stick with a solution to determine which RT
index to pass to deparseInsertSql that involves a bit of
reverse-engineering, whereby we base that on where the partition's
ResultRelInfo seems to have originated from. If it looks like it was
created by ExecInitModifyTable because the partition is one of the subplan
target rels, then use the RTE and the RT index as is. If not,
ExecInitPartitionInfo would have created it because the partition was
chosen as the tuple routing target. In that case, we have to freshly
create an RTE for the partition after copying most of the fields from the
parent's RTE. We're done if the partition was selected as routing target
for an INSERT. If for UPDATE, we also have to change the RT index to pass
to deparseInsertSql to that of the first subplan's target rel, because
that's what we use as varno of expressions contained in the partition's
ResultRelInfo. Phew!
Thanks,
Amit
