Re: A problem in ExecModifyTable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: 李杰(慎追) <adger(dot)lj(at)alibaba-inc(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: A problem in ExecModifyTable
Date: 2021-08-17 14:13:55
Message-ID: 1077841.1629209635@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I'd been looking at the code in ExecInitModifyTable() that's the same
> as what you pasted thinking you meant that. I think for the check for
> partitioned tables in ExecModifyTable() then it's likely just dead
> code. It seems to be causing a bit of confusion though, so might be
> worth doing something about. Copied in Tom to see what he thinks as
> it's one of his.

Yeah, it's dead code in the sense that we should never reach these
if-blocks with a partitioned table. I believe the reason I made it
like that is that the logic is concerned with which style of row identity
applies to a particular relkind, and in the planner we treat partitioned
tables as requiring this style of row identity, so that the right things
happen for their children. So the answer is basically "for consistency
with add_row_identity_columns".

Maybe we could instead have add_row_identity_columns do nothing for
a partitioned table, but I'm unconvinced of that.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2021-08-17 14:27:42 Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)
Previous Message Tom Lane 2021-08-17 13:39:30 Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode