On Thu, Aug 6, 2026 at 1:02 AM Alexander Korotkov <[email protected]> wrote:
>
> Actually, this makes me uneasy.  What about restricting SPLIT/MERGE to
> the case when generated columns matching between source partitions and
> parent.  This is the only solution I consider appropriate at this
> stage of development.
>

drop table if exists x;
CREATE TABLE x (id int, g int GENERATED ALWAYS AS (NULLIF(tableoid,
18470)) NOT NULL) partition by range(id);
CREATE TABLE x1 PARTITION OF x FOR VALUES FROM (10) TO (20);
CREATE TABLE x2 PARTITION OF x FOR VALUES FROM (20) TO (30);
ALTER TABLE x MERGE PARTITIONS (x1, x2) INTO x12;

It's possible that the new table x12's tableoid is 18470, and
MergePartitionsMoveRows, checkPartitionRowConstraints did nothing
about it.
So at the end of checkPartitionGenExprMatchesParent,
we can use expression_references_system_column(generation_expr) to
guard against such corner case, regardless of the generated column
kind.

Please check the attached diff to address this issue.

expression_references_system_column is a useful helper function that
can be reused in multiple places, so I also added its declaration.
In our context, we can use it in createTableConstraints, which is
better than pull_varattnos i think.
I also did pgindent on tablecmds.c

(I didn't review v2-0001, v2-0002).

Attachment: v2-0001-misc-fix-for-Don-t-recalculate-generated-columns-during-MERGE-S.nocfbot
Description: Binary data

Reply via email to