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 table inheritance stuff. While looking at MergeAttributesIntoExisting in src/backend/commands/tablecmds.c I did not notice any 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