Re: A problem in ExecModifyTable

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: A problem in ExecModifyTable
Дата
Msg-id CAApHDvoFokcvu_T2krcxH9nXHrj2SNcVaMxBS9wMix2cke1ofQ@mail.gmail.com
обсуждение исходный текст
Ответ на A problem in ExecModifyTable  ("李杰(慎追)" <adger.lj@alibaba-inc.com>)
Ответы 回复:A problem in ExecModifyTable
Список 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 по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side
Следующее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Diagnostic comment in LogicalIncreaseXminForSlot