On Tue, 23 Apr 2019 at 13:49, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote: > > On 2019/04/23 7:51, Alvaro Herrera wrote: > > To me, it sounds > > unintuitive to accept partitions that don't exactly match the order of > > the parent table; but it's been supported all along. > > You might know it already, but even though column sets of two tables may > appear identical, their TupleDescs still may not match due to dropped > columns being different in the two tables.
I think that's the most likely reason that the TupleDescs would differ at all. For RANGE partitions on time series data, it's quite likely that new partitions are periodically created to store new data. If the partitioned table those belong to evolved over time, gaining new columns and dropping columns that are no longer needed then some translation work will end up being required. From my work on 42f70cd9c, I know tuple conversion is not free, so it's pretty good that pg_dump will remove the need for maps in this case even with the proposed change. I imagine users randomly specifying columns for partitions in various random orders is a less likely scenario, although, it's entirely possible. Tom's point about being able to pg_dump a single partition and restore it somewhere without the parent (apart from an error in ATTACH PARTITION) seems like it could be useful too, so I'd say that the pg_dump change is a good one regardless. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
