Re: transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Wed, May 10, 2017 at 2:31 PM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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).

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