Re: [HACKERS] reload-through-the-top-parent switch the partition table - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] reload-through-the-top-parent switch the partition table
Date
Msg-id CA+TgmobsaUcSZbsOBqjOGjXprYrL8cSw0KVg=pfEGkZ1cT3raQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] reload-through-the-top-parent switch the partition table  (Rushabh Lathia <rushabh.lathia@gmail.com>)
Responses Re: [HACKERS] reload-through-the-top-parent switch the partition table  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Aug 2, 2017 at 1:01 AM, Rushabh Lathia <rushabh.lathia@gmail.com> wrote:
> Looking at the dbObjectTypePriority comments that seems like data
> restoration
> will *absolutely always* follow all CREATE TABLE commands.

Hmm.  I wasn't very convinced by those comments, but Tom's commit
a1ef01fe163b304760088e3e30eb22036910a495 convinces me that it has to
work that way.  So I think we are OK on that score.

The patch itself looks just fine on a quick glance, modulo the lack of
documentation, but I think we need to bikeshed the name of the flag.
--reload-through-root is clear as daylight to me, but I'm not sure
users will agree.   The lack of the word "partition" is perhaps a
significant flaw, and pg_dump doesn't really reload anything; it just
dumps.

The best thing I can come up with after brief thought is
--partition-data-via-root, but maybe somebody else has a better idea?

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] pgbench: Skipping the creating primary keys after initialization