On Tue, May 9, 2017 at 11:40 PM, Thomas Munro <thomas.mu...@enterprisedb.com> wrote: > On Wed, May 10, 2017 at 2:31 PM, Amit Langote > <langote_amit...@lab.ntt.co.jp> wrote: >> On 2017/05/10 6:51, Thomas Munro wrote: >>> No such problem exists for partition hierarchies since the tables all >>> appear as the same type to user code (though conversions may be >>> happening for technical reasons). >> >> To clarify a bit, there may exist differences in the ordering of columns, >> either between the parent and its partitions or between different >> partitions. For example, while parent's rowtype is (a int, b char, c >> float), a partition's may be (b char, a int, c float), and yet another >> partition may have (c float, a int, b char). If some user code happens to >> depend on the ordering of columns, selecting from the parent and selecting >> from a partition directly may return the same result but in different >> formats. > > Right. And the patch I posted converts all transition tuples it > collects from child tables to match the TupleDescriptor of the > relation you named, which it gets from > estate->es_root_result_relations[0]. Is that right? I suppose it > will be very common for partitions to have matching TupleDescriptors, > so the TupleConversionMap will usually be NULL meaning no conversion > is ever done. But in the inheritance case they might be different on > purpose, and in both inheritance and partitioning cases they might be > different in physical ways that aren't logically important as you said > (column order, dropped columns).
Hmm. What if the partitioning hierarchy contains foreign tables? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
