Re: [HACKERS] Bug in pg_dump --table and --exclude-table fordeclarative partition table handling. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Bug in pg_dump --table and --exclude-table fordeclarative partition table handling.
Date
Msg-id CA+TgmoZ6btZ9xBuH2HUX8GOJnZqTuY6+bzdmRMxVgUe9REPamw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, May 11, 2017 at 9:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeevan Ladhe <jeevan.ladhe@enterprisedb.com> writes:
>> On Thu, May 11, 2017 at 4:47 PM, Ashutosh Bapat <
>>> We add PARTITION OF clause for a table which is partition, so if the
>>> parent is not present while restoring, the restore is going to fail.
>
>> +1
>> But, similarly for inheritance if we dump a child table, it's dump is
>> broken as
>> of today. When we dump a child table we append "inherits(parenttab)" clause
>> at
>> the end of the DDL. Later when we try to restore this table on a database
>> not
>> having the parenttab, the restore fails.
>> So, I consider this as a bug.
>
> It sounds exactly what I'd expect.  In particular, given that pg_dump has
> worked that way for inherited tables from the beginning, it's hard to see
> any must-fix bugs here.

I agree.

> You could argue that it would be better for pg_dump to emit something
> like
>
>         CREATE TABLE c (...);
>         ALTER TABLE c INHERIT p;
>
> so that if p isn't around, at least c gets created.  And I think it
> *would* be better, probably.  But if that isn't a new feature then
> I don't know what is.  And partitioning really ought to track the
> behavior of inheritance here.

Hmm, I think that'd actually be worse, because it would break the use
case where you want to restore the old contents of one particular
inheritance child.  So you drop that child (but not the parent or any
other children) and then do a selective restore of that one child.
Right now that works fine, but it'll fail with an error if we try to
create the already-extant parent.

I think one answer to the original complaint might be to add a new
flag to pg_dump, something like --recursive-selection, maybe -r for
short, which makes --table, --exclude-table, and --exclude-table-data
cascade to inheritance descendents.  Then if you want to dump your
partition table's definition without picking up the partitions, you
can say pg_dump -t splat, and if you want the children as well you can
say pg_dump -r -t splat.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] Time based lag tracking for logical replication
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] SCRAM in the PG 10 release notes