| From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
|---|---|
| To: | andrewbille(at)gmail(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: BUG #16622: pg_dump produces erroneus ALTER TABLE statement for a table with an inherited generated column |
| Date: | 2020-09-18 09:38:15 |
| Message-ID: | 3B0AA616-F9E9-40F4-9350-2F82E6E88BC9@yesql.se |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
> On 18 Sep 2020, at 06:58, PG Bug reporting form <noreply(at)postgresql(dot)org> wrote:
> psql:dump.sql:50: ERROR: column "b" of relation "gtest1_1" is a generated
> column
I can reproduce this in git HEAD too. Off the cuff, ISTM that we should only
dump attrdefs for local columns during non-upgrade dumps? It works for normal
DEFAULTs but the restored db will have different :location for the attrdef.
For generated columns it errors out as shown above. I don't really follow the
reason for why we redo the normal DEFAULT for non-local columns today, is that
intentional?
The attached, potentially naive, patch fixes the above issue and passes pg_dump
and pg_upgrade tests.
cheers ./daniel
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Skip-dumping-column-defaults-for-inherited-cols.patch | application/octet-stream | 985 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Juan José Santamaría Flecha | 2020-09-18 10:47:06 | Re: BUG #15858: could not stat file - over 4GB |
| Previous Message | PG Bug reporting form | 2020-09-18 05:55:34 | BUG #16623: JSON select query result is getting differed when we change DB version |