On Fri, May 19, 2017 at 10:53 AM, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 5/18/17 16:21, Thomas Munro wrote:
>> That's because if you attach a partition with a different column
>> ordering,
>
> Is it intentional and sensible to allow that in the first place?  Or was
> it just inherited from inheritance?

Can't speak for the authors but I'm sure it's intentional.  Making an
existing table fit into a partitioning hierarchy is a useful thing to
be able to do, and you can't reorder columns.

>> pg_dump dumps it with a normal CREATE TABLE ... PARTITION OF
>> ... command, so the ordering it lost.
>
> So it appears that either the above should be prohibited or pg_dump
> should be fixed.

pg_dump already knows how to do create-then-attach for binary
upgrades, for a less debatable reason: tuple format must be preserved.
To make normal dump/restore preserve the order, we could either make
it *always* write create-then-attach, or do it only if required.  I'd
vote for doing it only if required because of different column order,
because I don't want to see 1,000 partitions dumped in "long format"
when the short and sweet CREATE... PARTITION OF ... syntax could
usually be used.

-- 
Thomas Munro
http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to