pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
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: Wed, 04 Dec 2019 15:36:19 -0500
Message-ID: <31905.1575491779@sss.pgh.pa.us> (raw)
In-Reply-To: <fd559544-274c-f514-d8bf-358d2c539455@2ndquadrant.com>
References: <15830.1575468847@sss.pgh.pa.us>
	<fd559544-274c-f514-d8bf-358d2c539455@2ndquadrant.com>

Peter Eisentraut <peter.eisentraut@2ndquadrant.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





view thread (37+ messages)  latest in thread

Message-ID: <31905.1575491779@sss.pgh.pa.us>
Permalink:  ../31905.1575491779@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/31905.1575491779@sss.pgh.pa.us

 · 

reply

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: <31905.1575491779@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