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
