From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: pg_dump is broken for partition tablespaces |
Date: | 2019-03-06 07:19:00 |
Message-ID: | 20190306071900.GI30982@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Mar 06, 2019 at 07:45:06PM +1300, David Rowley wrote:
> Partitioned indexes have this similar inherit tablespace from parent
> feature, so ca4103025dfe26 was intended to align the behaviour of the
> two. Partitioned indexes happen not to suffer from the same issue as
> the indexes are attached after their creation similar to what I
> propose above.
>
> Can anyone see any fundamental reason that we should not create a
> partitioned table by doing CREATE TABLE followed by ATTACH PARTITION?
> If not, I'll write a patch that fixes it that way.
The part for partitioned indexes is already battle-proven, so if the
part for partitioned tables can be consolidated the same way that
would be really nice.
> As far as I can see, the biggest fundamental difference with doing
> things this way will be that the column order of partitions will be
> preserved, where before it would inherit the order of the partitioned
> table. I'm a little unsure if doing this column reordering was an
> intended side-effect or not.
I don't see any direct issues with that to be honest thinking about
it..
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-03-06 08:27:30 | Re: BUG #15668: Server crash in transformPartitionRangeBounds |
Previous Message | Rushabh Lathia | 2019-03-06 07:13:17 | ECPG regression with DECLARE STATEMENT support |