From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | 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: | 2020-09-25 14:16:03 |
Message-ID: | 1853888.1601043363@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> The proposed patches will cause the last statement to be omitted, but
> that still won't recreate the original state. The problem is that there
> is no command to make a column generated afterwards, like the SET
> DEFAULT command, so we can't dump it like this.
Right. I'm not even sure what such a command should do ... would it run
through all existing rows and update them to be the GENERATED value?
> We could probably fix this by having ALTER TABLE ONLY / DROP EXPRESSION
> update the attlocal column of direct children to true, to make the
> catalog state look like something that can be restored. However, that's
> a fair amount of complicated code, so for now I propose to just prohibit
> this command, meaning you can't use ONLY in this command if there are
> children. This is new in PG13, so this change would have very limited
> impact in practice.
+1. At this point we would want some fairly un-complicated fix for
the v13 branch anyhow, and this seems to fit the bill. (Also, having
child columns suddenly grow an attislocal property doesn't seem to meet
the principle of least surprise.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2020-09-25 14:30:00 | Re: Probable documentation errors or improvements |
Previous Message | Masahiko Sawada | 2020-09-25 14:11:27 | Re: Transactions involving multiple postgres foreign servers, take 2 |