From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Santosh Udupi <email(at)hitha(dot)net> |
Cc: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: pg_restore - generated column - not populating |
Date: | 2021-02-24 01:03:06 |
Message-ID: | 4007188.1614128586@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-general |
[ redirecting to pgsql-bugs ]
Santosh Udupi <email(at)hitha(dot)net> writes:
> Here is my table structure.
Indeed, this looks pretty busted, both in v13 and HEAD. It seems that
pg_dump is not coping well with GENERATED columns attached to a
partition parent table. I made the attached script with a bit of
sample data, loaded it into an empty database, and dumped it.
The dump is evidently assuming that ALTER TABLE ATTACH PARTITION
is going to cause the generated-ness of the columns to propagate
to the children, but it doesn't. There also seems to be considerable
confusion about which columns of the child tables should be included
in the dumped data.
I suspect this example is revealing bugs in both the backend
(ATTACH PARTITION ought to take care of this, no?) and pg_dump
(the backend can't be blamed for pg_dump's choices of columns
to dump). Peter?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
partition_generated.sql | text/plain | 2.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Santosh Udupi | 2021-02-24 02:18:06 | Re: pg_restore - generated column - not populating |
Previous Message | Santosh Udupi | 2021-02-24 00:46:03 | Re: pg_restore - generated column - not populating |
From | Date | Subject | |
---|---|---|---|
Next Message | David Wheeler | 2021-02-24 01:58:43 | Re: Permission inconsistency with views that call functions |
Previous Message | Santosh Udupi | 2021-02-24 00:46:03 | Re: pg_restore - generated column - not populating |