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: Mon, 03 Feb 2020 14:32:41 -0500
Message-ID: <24369.1580758361@sss.pgh.pa.us> (raw)
In-Reply-To: <d6ebcc2e-3e6f-6915-6616-70ef665aed66@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>
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2019-12-04 21:36, Tom Lane wrote:
>> I wonder if the right fix is to not generate a DO_ATTRDEF
>> object at all for generated columns in child tables. Am
>> I right in guessing that we propagate generated-ness to
>> child tables automatically?
> Right. New patch using that approach attached. (Could use more
> extensive comments.)
This looks more plausible than the previous attempt, but it's clearly
still not right, because this is what it changes in the regression
test dump:
inline patch 1: r.dump.patch (+1/-8 lines) download inline-1.patch--- r.dump.head 2020-02-03 14:16:15.774305437 -0500+++ r.dump.patch 2020-02-03 14:18:08.599109703 -0500@@ -15244,14 +15244,7 @@
-- Name: gtest1_1 b; Type: DEFAULT; Schema: public; Owner: postgres
--
-ALTER TABLE ONLY public.gtest1_1 ALTER COLUMN b SET DEFAULT (a * 2);-------- Name: gtest30_1 b; Type: DEFAULT; Schema: public; Owner: postgres-----ALTER TABLE ONLY public.gtest30_1 ALTER COLUMN b SET DEFAULT (a * 2);+ALTER TABLE ONLY public.gtest1_1 ALTER COLUMN b SET DEFAULT NULL;
--
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.
Things are evidently also going wrong for "gtest1_1". In that case
the generated property is inherited from the parent gtest1, so we
shouldn't be emitting anything ... how come the patch fails to
make it do that?
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: <24369.1580758361@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