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

From Tom Lane
Subject Re: A problem in ExecModifyTable
Date
Msg-id 1077841.1629209635@sss.pgh.pa.us
Whole thread Raw
In response to Re: A problem in ExecModifyTable  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
David Rowley <dgrowleyml@gmail.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode
Next
From: Ranier Vilela
Date:
Subject: Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)