From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Dumping/restoring fails on inherited generated column |
Date: | 2021-02-03 15:24:12 |
Message-ID: | 2903e1ce-0765-cbeb-dd58-8fab7f6596a3@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021-01-29 17:41, Tom Lane wrote:
> However ... this doesn't solve all the cases noted in this thread.
> In the first example I gave at [1],
>
> d3=# create table parent (f1 int default 2);
> CREATE TABLE
> d3=# create table child (f1 int default 3) inherits(parent);
> NOTICE: merging column "f1" with inherited definition
> CREATE TABLE
> d3=# create table child2() inherits(parent);
> CREATE TABLE
> d3=# alter table child2 alter column f1 set default 42;
> ALTER TABLE
>
> pg_dump still fails to restore child2.f1's non-inherited default.
> That's probably a pre-existing problem, since it doesn't involve
> GENERATED at all, but we shouldn't forget about it.
> [1] https://www.postgresql.org/message-id/660925.1601397436%40sss.pgh.pa.us
I can't tell what the problem is in this example. I tried with PG11,
12, and master, and the schema dump comes out with those same four
commands and they restore correctly AFAICT.
--
Peter Eisentraut
2ndQuadrant, an EDB company
https://www.2ndquadrant.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-02-03 15:31:38 | Re: Dumping/restoring fails on inherited generated column |
Previous Message | Peter Eisentraut | 2021-02-03 15:21:17 | Re: Prevent printing "next step instructions" in initdb and pg_upgrade |