Re: ATTACH PARTITION seems to ignore column generation status

Hello,

11.01.2023 23:58, Tom Lane wrote:
> Amit Langote<amitlangote09(at)gmail(dot)com> writes:
>> I've updated your disallow-generated-child-columns-2.patch to do this,
>> and have also merged the delta post that I had attached with my last
>> email, whose contents you sound to agree with.
> Pushed with some further work to improve the handling of multiple-
> inheritance cases. We still need to insist that all or none of the
> parent columns are generated, but we don't have to require their
> generation expressions to be alike: that can be resolved by letting
> the child table override the expression, much as we've long done for
> plain default expressions. (This did need some work in pg_dump
> after all.) I'm pretty happy with where this turned out.
I've encountered a query that triggers an assert added in that commit:
CREATE TABLE t(a int, b int GENERATED ALWAYS AS (a) STORED) PARTITION BY
RANGE (a);
CREATE TABLE tp PARTITION OF t(b DEFAULT 1) FOR VALUES FROM (0) to (1);

Core was generated by `postgres: law regression [local] CREATE
TABLE                                 '.
Program terminated with signal SIGABRT, Aborted.

warning: Section `.reg-xstate/3152655' in core file too small.
#0  __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140460372887360) at ./nptl/pthread_kill.c:44
44      ./nptl/pthread_kill.c: No such file or directory.
(gdb) bt
#0  __pthread_kill_implementation (no_tid=0, signo=6,
threadid=140460372887360) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=140460372887360) at
./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=140460372887360, signo=signo(at)entry=6)
at ./nptl/pthread_kill.c:89
#3  0x00007fbf79f0e476 in __GI_raise (sig=sig(at)entry=6) at
../sysdeps/posix/raise.c:26
#4  0x00007fbf79ef47f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x000055e76b35b322 in ExceptionalCondition (
    conditionName=conditionName(at)entry=0x55e76b4a2240
"!(coldef->generated && !restdef->generated)",
    fileName=fileName(at)entry=0x55e76b49ec71 "tablecmds.c",
lineNumber=lineNumber(at)entry=3028) at assert.c:66
#6  0x000055e76afef8c3 in MergeAttributes (schema=0x55e76d480318,
supers=supers(at)entry=0x55e76d474c18,
    relpersistence=112 'p', is_partition=true,
supconstr=supconstr(at)entry=0x7ffe945a3768) at tablecmds.c:3028
#7  0x000055e76aff0ef2 in DefineRelation
(stmt=stmt(at)entry=0x55e76d44b2d8, relkind=relkind(at)entry=114 'r', ownerId=10,
    ownerId(at)entry=0, typaddress=typaddress(at)entry=0x0,
    queryString=queryString(at)entry=0x55e76d44a408 "CREATE TABLE tp
PARTITION OF t(b DEFAULT 1) FOR VALUES FROM (0) to (1);") at tablecmds.c:861
...

Without asserts enables, the partition created successfully, and
INSERT INTO t VALUES(0);
SELECT * FROM t;
yields:
a | b
---+---
0 | 1
(1 row)

Is this behavior expected?

Best regards,
Alexander