On Sunday, August 23, 2026 3:37 PM Zhijie Hou (Fujitsu) <[email protected]> wrote: > > On Thursday, August 20, 2026 8:46 PM Alexander Korotkov > <[email protected]> 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
