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
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 |