Re: Dumping/restoring fails on inherited generated column

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

In response to

Browse pgsql-hackers by date

  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