Hello
I found a simple test case:
CREATE TABLE test(id int NOT NULL, gen int GENERATED ALWAYS AS (id + 1) STORED) partition by range (id);
create table test_part_create partition of test for values from ( 0) to (10);
create table test_part_attach (id int NOT NULL, gen int);
alter table test attach partition test_part_attach for values from (10) to (20);
postgres=# \d test_part_create
Table "public.test_part_create"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+-------------------------------------
id | integer | | not null |
gen | integer | | | generated always as (id + 1) stored
Partition of: test FOR VALUES FROM (0) TO (10)
postgres=# \d test_part_attach
Table "public.test_part_attach"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
id | integer | | not null |
gen | integer | | |
Partition of: test FOR VALUES FROM (10) TO (20)
Both partitions are attached, but alter table attach patition did not check nor enforce a generated column. Same for
tableinheritance stuff. While looking at MergeAttributesIntoExisting in src/backend/commands/tablecmds.c I did not
noticeany special handling or comments for attgenerated. It's an oversight and a bug?
Also,
postgres=# alter table test alter COLUMN gen drop expression ;
ERROR: column "gen" of relation "test_part_attach" is not a stored generated column
Regards, Sergei
