Re: A problem in ExecModifyTable

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: 李杰(慎追) <adger(dot)lj(at)alibaba-inc(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: A problem in ExecModifyTable
Date: 2021-08-17 05:41:16
Message-ID: CAApHDvoFokcvu_T2krcxH9nXHrj2SNcVaMxBS9wMix2cke1ofQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, 17 Aug 2021 at 15:56, 李杰(慎追) <adger(dot)lj(at)alibaba-inc(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2021-08-17 06:28:24 Re: Diagnostic comment in LogicalIncreaseXminForSlot
Previous Message Amit Kapila 2021-08-17 05:35:26 Re: Skipping logical replication transactions on subscriber side