From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Dumping/restoring fails on inherited generated column
Date: Fri, 07 Feb 2020 17:16:37 -0500
Message-ID: <27557.1581113797@sss.pgh.pa.us> (raw)
In-Reply-To: <b1c831dd-d520-5e7f-0304-0eeed39c9996@2ndquadrant.com>
References: <15830.1575468847@sss.pgh.pa.us>
<fd559544-274c-f514-d8bf-358d2c539455@2ndquadrant.com>
<31905.1575491779@sss.pgh.pa.us>
<d6ebcc2e-3e6f-6915-6616-70ef665aed66@2ndquadrant.com>
<24369.1580758361@sss.pgh.pa.us>
<b1c831dd-d520-5e7f-0304-0eeed39c9996@2ndquadrant.com>
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-02-03 20:32, Tom Lane wrote:
>> This is showing us at least two distinct problems. Now as for
>> "gtest30_1", what we have is that in the parent table "gtest30", column b
>> exists but it has no default; the generated property is only added
>> at the child table gtest30_1. So we need to emit ALTER COLUMN SET
>> GENERATED ALWAYS for gtest30_1.b. HEAD is already doing the wrong
>> thing there (it's emitting the expression, but as a plain default
>> not GENERATED). And this patch makes it emit nothing, even worse.
>> I think the key point here is that "attislocal" refers to whether the
>> column itself is locally defined, not to whether its default is.
> This is a bit of a mess. Let me explain my thinking on generated
> columns versus inheritance.
> If a parent table has a generated column, then any inherited column must
> also be generated and use the same expression. (Otherwise querying the
> parent table would produce results that are inconsistent with the
> generation expression if the rows come from the child table.)
Check.
> If a parent table has a column that is not generated, then I think it
> would be semantically sound if a child table had that same column but
> generated. However, I think it would be very tricky to support this
> correctly, and it doesn't seem useful enough, so I'd rather not do it.
So ... why is that so hard exactly? AFAICS, the existing regression
test cases show that it works fine. Except that pg_dump gets it wrong.
In general, we surely want to support child columns that have defaults
different from the parent column's default, so this doesn't seem quite
that huge a leap to me.
> That's what the gtest30_1 case above shows. It's not even clear whether
> it's possible to dump this correctly in all cases because the syntax
> that you allude to "turn this existing column into a generated column"
> does not exist.
I'm a little confused by that statement. What is this doing, if not
that:
regression=# create table foo (f1 int not null);
CREATE TABLE
regression=# alter table foo alter column f1 add generated always as identity;
ALTER TABLE
regression=# \d foo
Table "public.foo"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+------------------------------
f1 | integer | | not null | generated always as identity
If we didn't have things like ALTER ... SET GENERATED and
ALTER ... DROP EXPRESSION, I'd be a lot more content to accept
the position that generated-ness is an immutable column property.
But we do have those things, so the restriction you're proposing
seems mighty arbitrary.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, peter.eisentraut@2ndquadrant.com, pgsql-hackers@lists.postgresql.org
Subject: Re: Dumping/restoring fails on inherited generated column
In-Reply-To: <27557.1581113797@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox