Re: BUG #16622: pg_dump produces erroneus ALTER TABLE statement for a table with an inherited generated column

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

In response to

Responses

Browse pgsql-bugs by date

  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