RE: MERGE/SPLIT PARTITIONS issues/questions

On Sunday, August 23, 2026 3:37 PM Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Thursday, August 20, 2026 8:46 PM Alexander Korotkov
> <aekorotkov(at)gmail(dot)com> wrote:
> >
> > Added as 0005 patch to the patchset.
> >
>
> I took a look at 0001 and 0002.
>
> 0001 looks OK to me.
>
> For 0002, I think we should also disallow the command when the partition is
> explicitly listed in the publication's EXCEPT TABLE list. Otherwise, changes on
> partitions that were previously ignored would start being replicated after
> splitting (or merging), which could be unexpected.

After rechecking, I realized that adding partition into EXCEPT TABLE list is not
supported for now, so I think the current check is sufficient, so please ignore
the above comment.

>
> BTW, this patch also disallows SPLIT/MERGE when both the parent and child
> tables are explicitly added to a publication. That case is actually safe, since
> publishing the parent already covers the partition. But if the intent is to keep
> the check simple and avoid adding complexity for this infrequent case, I think
> that's acceptable - though it might be worth adding a comment to explain the
> reasoning.

In addition to the above point, I noticed a similar case in
checkPartitionSchemaPublications():

+/*
+ * checkPartitionSchemaPublications: refuse MERGE/SPLIT when the new partition(s)
+ * would land in a schema whose FOR TABLES IN SCHEMA publications differ from
+ * those of the source partition(s).

The function decides solely by comparing the schemas' FOR TABLES IN SCHEMA
publications. But a publication can mix both forms, e.g.:

CREATE PUBLICATION pub FOR TABLES IN SCHEMA sch1, TABLE parent;

Since the publication covers the partitioned table itself, all of its partitions
are implicitly covered no matter which schema they live in. So even if the new
partition lands in a different schema after MERGE/SPLIT, its coverage by such a
publication doesn't change, and refusing the operation seems unnecessary. If
releasing this case looks complex, adding some comments would be better.

Best Regards,
Zhijie Hou