On Wed, Aug 5, 2026 at 3:27 AM jian he <jian.universality@gmail.com> wrote:
>
> On Tue, Aug 4, 2026 at 3:26 AM Alexander Korotkov <aekorotkov@gmail.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?
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
