Re: [HACKERS] different column orders in regression test database
От | Thomas Munro |
---|---|
Тема | Re: [HACKERS] different column orders in regression test database |
Дата | |
Msg-id | CAEepm=0CCWBaVAcYd_5OBbBiKBLT-oJJowx3kq3cVqxS5MRr3Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] different column orders in regression test database (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] different column orders in regression test database
|
Список | pgsql-hackers |
On Fri, May 19, 2017 at 10:53 AM, Peter Eisentraut <peter.eisentraut@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
В списке pgsql-hackers по дате отправления: