| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | 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 19:18:33 |
| Message-ID: | 22de27f6-7096-8d96-4619-7b882932ca25@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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/
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-WIP-Fix-ALTER-TABLE-INHERIT-with-generated-columns.patch | text/plain | 5.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2021-02-03 20:13:17 | Re: Next Commitfest Manager. |
| Previous Message | Bruce Momjian | 2021-02-03 18:16:32 | Re: Key management with tests |