Re: MERGE issues around inheritance

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> 于2025年5月26日周一 18:41写道：

> On Mon, 26 May 2025 at 07:46, Tender Wang <tndrwang(at)gmail(dot)com> wrote:
> >
> > Hi Dean,
> >
> > "it is possible for the parent to be excluded from the
> > plan and so all of the entries in the resultRelInfo array may be for
> > different relations than rootResultRelInfo."
> >
> > I didn't fully understand the above sentence. Can you give me more
> information or an example?
> > If the parent is excluded from the plan, the first entry in the
> resultRelInfo array will not be the parent but some surviving child.
>
> There's an example in the updated regression tests. A non-inherited
> CHECK constraint on the parent causes the planner to exclude the
> parent from the relations being scanned and from the resultRelInfo
> array, so the first resultRelInfo entry is for a child relation.
>

Yes, it is. I debugged the updated regression tests. It would crash if
resultRelInfo were used instead of rootResultInfo.
Is that the reason that we must use rootResultInfo? Are there other things
that I miss?

>That's a different check. "rootRelInfo != mtstate->resultRelInfo"
>checks that we're dealing with an inheritance/partitioned case (see
>the code in ExecInitModifyTable() that sets up rootRelInfo). However,
>in the inherited case, when rootRelInfo and mtstate->resultRelInfo
>point to different ResultRelInfo structures, it is possible (actually
>quite likely) that they will internally point to the same Relation. In
>that case, we do still need to set up the WCO list, RETURNING list and
>projection for rootRelInfo, but we don't need to map attribute
>numbers. Building the attribute map looks like it's O(n^2) in the
>number of attributes, so it's worth avoiding if we can.
Yeah, Jian's idea is right.

--
Thanks,
Tender Wang