Dean Rasheed <dean.a.rash...@gmail.com> 于2025年5月28日周三 18:26写道：
> On Mon, 26 May 2025 at 12:50, Tender Wang <tndrw...@gmail.com> wrote: > > > >> > "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? > > > > Yes. To work correctly for an inherited table, ExecInsert() must be > passed a pointer to a ResultRelInfo structure that points to the > parent table. > > As I mentioned before, this goes back to commit 387f9ed0a08, so it's > worth reading that in more detail. > > Prior to commit 387f9ed0a08, rootResultInfo was equal to resultRelInfo > for an inherited table, which was wrong because that could point to a > child table, if the parent table was excluded from the plan. > > Commit 387f9ed0a08 fixed that by changing the planner so that it set > ModifyTable.rootRelation to the index of the parent table, if it was > an inherited table. As a result, starting from that commit, for an > inherited table, rootResultInfo is a different ResultRelInfo structure > which always points to the parent table, making it the correct thing > to pass to ExecInsert() under all circumstances. > Yeah. Your explanation above made me understand completely. Thanks for your explanation. > > The thing that was overlooked was that the separate ResultRelInfo > structure in rootResultInfo, and the insert projection, weren't being > correctly initialised for MERGE, which is what this patch aims to fix. > Yes, it is. > Unless there are any further comments, I plan to commit it in a day or > so. > I don't have any other comments. It looks good for me. -- Thanks, Tender Wang
