Re: pg_restore - generated column - not populating

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

In response to

Responses

Browse pgsql-bugs by date

  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

Browse pgsql-general by date

  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