From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Dumping/restoring fails on inherited generated column |
Date: | 2019-12-04 20:36:19 |
Message-ID: | 31905.1575491779@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 2019-12-04 15:14, Tom Lane wrote:
>> It looks like gtest1_1 inherits column "b" from gtest1, so possibly
>> pg_dump is just confused about the combination of inheritance and
>> generated columns.
> Yeah, there was some stuff about the "separate" dumping of defaults that
> I apparently forgot to address. The attached patch fixes it. I'll see
> about adding a test case for it, too.
I don't think this is right. It will probably misbehave if the
"generated" expression has any interesting dependencies:
1. You didn't duplicate the behavior of the existing separate=false
case, where it adds a dependency to try to force the default's
dependencies to exist before the table is created.
2. If that dependency turns out to create a dependency loop, the
later code will break the loop by setting separate=true anyway.
Then what?
I also find it improbable that overriding the !shouldPrintColumn
test is really the right thing. That test is what distinguishes
the is-a-parent-table from the is-a-child-table cases, and the
core of the issue here seems to be that we need to treat those
differently.
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-12-04 21:34:42 | Re: more backtraces |
Previous Message | Peter Eisentraut | 2019-12-04 20:31:01 | Re: more backtraces |