Re: Dumping/restoring fails on inherited generated column

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, andrewbille(at)gmail(dot)com, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Dumping/restoring fails on inherited generated column
Date: 2020-09-29 20:17:05
Message-ID: 718578.1601410625@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 29 Sep 2020, at 18:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2020-09-29 20:31:07 Re: Yet another fast GiST build
Previous Message Andrew Dunstan 2020-09-29 20:16:14 Re: BLOB / CLOB support in PostgreSQL