> Copying the value of generated column "as is" can produce data that differs > from > what the generated expression would compute if any merged partition's > generation > expression differs from the partitioned table's.
I think this would be probably fine, as we can get the same effect by replacing a function used by the expression, a preexisting condition for many existing cases. But I do agree that requiring the same expression is a better approach. Also, not directly related to this patch, but now that I looked into this, I can still use tableoids for check constraints with a text cast: CREATE TABLE t (i int) PARTITION BY RANGE (i); CREATE TABLE tp_0_1 PARTITION OF t FOR VALUES FROM (0) TO (1); CREATE TABLE tp_1_2 PARTITION OF t FOR VALUES FROM (1) TO (2); ALTER TABLE t ADD CONSTRAINT cc CHECK (tableoid::regclass::text <> 'tp_0_2'); INSERT INTO t VALUES (0),(1); ALTER TABLE t MERGE PARTITIONS (tp_0_1, tp_1_2) INTO tp_0_2; -- SUCCESS, but should ERROR instead? And another question I realized while looking at differences to other rewrite operators: currently merge/split doesn't fire a rewrite event trigger, but shouldn't it? For the replication changes: shouldn't we also restrict schema changes? `TABLES IN SCHEMA` can still be problematic if the parent and the specific partitions are in different schemas, they either get published or unpublished. + <command>ALTER TABLE ... MERGE PARTITIONS</command> is a schema change and + is not itself replicated to logical replication subscribers; to reflect it + on a subscriber, run the equivalent command there, or drop and recreate + the affected partitions and refresh the subscription. I think this still results in my original (3) data loss scenario, so I don't think it's a good idea to recommend it. For example if we MERGE + UPDATE/INSERT on the publisher, the subscriber worker error-loops on the merged partition not existing. We replay the MERGE locally on the subscriber, the worker continues before we have a chance to run REFRESH PUBLICATION and discards the UPDATE/INSERT.
