Re: A problem in ExecModifyTable - Mailing list pgsql-hackers

From David Rowley
Subject Re: A problem in ExecModifyTable
Date
Msg-id CAApHDvoFokcvu_T2krcxH9nXHrj2SNcVaMxBS9wMix2cke1ofQ@mail.gmail.com
Whole thread Raw
In response to A problem in ExecModifyTable  ("李杰(慎追)" <adger.lj@alibaba-inc.com>)
Responses 回复:A problem in ExecModifyTable  ("李杰(慎追)" <adger.lj@alibaba-inc.com>)
List pgsql-hackers
On Tue, 17 Aug 2021 at 15:56, 李杰(慎追) <adger.lj@alibaba-inc.com> wrote:
> According to my understanding, the parent table of a partitioned table does not store any tuples.
> Then why is "relkind = = RELKIND_PARTITIONED_TABLE" suddenly added here ?

We'll need some sort of ResultRelInfo in the case that all partitions
are pruned.  Using the one for the partitioned table is convenient.  I
believe that's required if there are any statement-level triggers on
the partitioned table or if there's a RETURNING clause.

> There is no comment on this point in the code.
> Can you answer my confusion? Be deeply grateful.

Yeah maybe. It's not exactly close by, but one in grouping_planner
mentions this:

/*
* We managed to exclude every child rel, so generate a
* dummy one-relation plan using info for the top target
* rel (even though that may not be a leaf target).
* Although it's clear that no data will be updated or
* deleted, we still need to have a ModifyTable node so
* that any statement triggers will be executed.  (This
* could be cleaner if we fixed nodeModifyTable.c to allow
* zero target relations, but that probably wouldn't be a
* net win.)
*/

David



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Ashutosh Bapat
Date:
Subject: Re: Diagnostic comment in LogicalIncreaseXminForSlot