Re: Dumping/restoring fails on inherited generated column - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Dumping/restoring fails on inherited generated column
Date
Msg-id 718578.1601410625@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dumping/restoring fails on inherited generated column  (Daniel Gustafsson <daniel@yesql.se>)
List 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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: BLOB / CLOB support in PostgreSQL
Next
From: Heikki Linnakangas
Date:
Subject: Re: Yet another fast GiST build