Re: MERGE/SPLIT PARTITIONS issues/questions

On Sat, Aug 1, 2026 at 7:11 PM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> > As a result, if the table contains generated
> > columns, the data in the newly created partition may not be identical to the
> > combined contents of the merged partitions.
> >
> > Therefore, when the partitioned table contains generated columns, we must
> > reverify NOT NULL constraints, CHECK constraints, and foreign key constraints
> > for ALTER TABLE ... MERGE PARTITION.
>
> Yes, we can certainly can patch it this way. But should we? This
> current behavior is inconsistent with how generated columns behave
> with other SQL commands. That's why I didn't attach a patch in my
> previous emails, I think the current way this behaves is wrong.
>
> My proposal would be to reject MERGE if it would cause a difference in
> generator expressions (or if it causes any other surprising changes),
> and keep the exact definition of the partition for SPLIT. Otherwise we
> end up with a surprising behavior in PG19, and if we want to fix it in
> later releases, it'll be a significant behavior change between major
> versions for the same command.

For ALTER TABLE pp MERGE PARTITIONS (pp1, pp2) INTO pp12, a CHECK constraint
that exists only on pp2 surely should not apply to the new pp12. Otherwise, that
constraint would also end up being enforced against pp1's data, regardless of
whether pp1 actually satisfies its definition, that would seem weird, IMHO.

IMHO, it makes sense to drop each individual partition's {indexes, constraints,
column DEFAULTs, foreign keys, triggers, reloptions, custom tablespace, table
AM, per-column settings, security labels, ACLs, RLS policies}, and instead have
them inherit/depend on the parent's definitions.

The main reason I favor this approach: regrading the table's depent(indexes,
constraints etc) partitions being merged can differ from one another, so there's
no good justification for favoring any single partition's definitions over the
others.

For this case, ALTER TABLE MERGE PARTITIONS should let the new
partition use the partitioned table's generation expression, i think.