Re: Dumping/restoring fails on inherited generated column - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: Dumping/restoring fails on inherited generated column
Date
Msg-id CALNJ-vS1PtJBk3v73Bq3dM9J46=P3jAcXOLjjtZ7w2fPYsg-7A@mail.gmail.com
Whole thread Raw
In response to Re: Dumping/restoring fails on inherited generated column  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: Dumping/restoring fails on inherited generated column  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hi,
+           if (attribute->attgenerated && !childatt->attgenerated)
+               ereport(ERROR,
...
+           if (attribute->attgenerated && childatt->attgenerated)
+           {

Looks like for the second if statement, checking attribute->attgenerated should be enough (due to the check from the first if statement).

Cheers

On Wed, Feb 3, 2021 at 11:18 AM Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 2021-01-29 17:41, Tom Lane wrote:
> Also, in the example from [2],
>
> d3=# create table pp1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED);
> CREATE TABLE
> d3=# create table cc1 (a int, b int GENERATED ALWAYS AS (a * 3) STORED);
> CREATE TABLE
> d3=# alter table cc1 inherit pp1;
> ALTER TABLE
>
> pg_dump now omits to dump cc1's generation expression, which seems
> strictly worse than before.  Admittedly, the backend likely ought to
> be rejecting this scenario, but it doesn't do so today.
>
> [2]https://www.postgresql.org/message-id/661371.1601398006%40sss.pgh.pa.us

Here is a WIP patch to address this.  Probably needs another look for
column number mapping and all the usual stuff, but the basic idea should
be okay.

--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: DROP TABLE can crash the replication sync worker
Next
From: Bruce Momjian
Date:
Subject: Re: Multiple full page writes in a single checkpoint?