Re: Dumping/restoring fails on inherited generated column
| От | Zhihong Yu |
|---|---|
| Тема | Re: Dumping/restoring fails on inherited generated column |
| Дата | |
| Msg-id | CALNJ-vS1PtJBk3v73Bq3dM9J46=P3jAcXOLjjtZ7w2fPYsg-7A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Dumping/restoring fails on inherited generated column (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
| Ответы |
Re: Dumping/restoring fails on inherited generated column
|
| Список | pgsql-hackers |
Hi,
+ if (attribute->attgenerated && !childatt->attgenerated)
+ ereport(ERROR,
+ 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 по дате отправления: