Horton

Re: Dumping/restoring fails on inherited generated column

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Daniel Gustafsson <daniel@yesql.se>
Cc: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>, andrewbille@gmail.com, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-09-29T20:17:05Z
Lists: pgsql-hackers 
Daniel Gustafsson <daniel@yesql.se> writes:
> On 29 Sep 2020, at 18:37, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> This does not cause child2.f1's attislocal property to become
>> true.  Maybe it should have, but it's probably too late for
>> that; at least, pg_dump couldn't assume it's true in older
>> servers.  

> Do you recall the rationale for it not being set to true?  I didn't spot
> anything in the commit history. Intuitively it seems a tad odd.

I'd bet the explanation is mostly that it didn't occur to anyone
that SET DEFAULT should do that.  I'm not really proposing that it
should either.  If we were to make any catalog changes in response
to this, what I'd vote for is to add an "inherited" flag to
pg_attrdef.  (I'm not quite sure if a bool would be sufficient,
or if we'd need to go to the same extent as pg_attribute does,
and have a bool plus an inheritance count.)

Of course, that line of thought does not lead to anything
back-patchable.  But pg_dump would have to be prepared to cope
with the situation in older servers in any case.

			regards, tom lane

Commits

  1. Fix ALTER TABLE / INHERIT with generated columns

  2. pg_dump: Fix dumping of inherited generated columns

  3. Disallow ALTER TABLE ONLY / DROP EXPRESSION

  4. Fix several DDL issues of generated columns versus inheritance