On Wed, Aug 5, 2026 at 3:27 AM jian he <[email protected]> wrote: > > On Tue, Aug 4, 2026 at 3:26 AM Alexander Korotkov <[email protected]> > wrote: > > > > I agree this behavior is incorrect. The patch 0003 implements copying > > values of generated columns "as is". The exclusion are expressions > > containing tableoid (system column which will change after completion > > of MERGE/SPLIT DDL). Reject this case for now. In future we may > > implement recalculation of such generated columns and further > > constraints re-validation (if needed). > > 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. > > For example: > DROP TABLE if exists t, tp_0_1, tp_0_2; > CREATE TABLE t ( > id int, > g int GENERATED ALWAYS AS (NULLIF(id, 1)) STORED NOT NULL) PARTITION > BY RANGE (id); > CREATE TABLE tp_0_1 (g int GENERATED ALWAYS AS (id) STORED NOT NULL, id int); > ALTER TABLE t ATTACH PARTITION tp_0_1 FOR VALUES FROM (0) TO (10); > CREATE TABLE tp_1_2 PARTITION OF t FOR VALUES FROM (10) TO (20); > INSERT INTO t VALUES (1), (2); > ALTER TABLE t MERGE PARTITIONS (tp_0_1, tp_1_2) INTO tp_0_2; > > Now the generation expression for column g in tp_0_2 is ``NULLIF(id, > 1) STORED``, > but the existing data (SELECT g FROM tp_0_2;) does not match what that > expression would compute. > > This seems not OK?
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. ------ Regards, Alexander Korotkov Supabase
v2-0003-Don-t-recalculate-generated-columns-during-MERGE-.patch
Description: Binary data
v2-0001-Don-t-logically-decode-MERGE-SPLIT-PARTITION-row-.patch
Description: Binary data
v2-0002-Peserve-replica-identity-and-publications-in-MERG.patch
Description: Binary data
