Re: MERGE/SPLIT PARTITIONS issues/questions

On Tue, Aug 4, 2026 at 3:26 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> 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?