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

On Tue, May 9, 2017 at 11:40 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> 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).

Hmm. What if the partitioning hierarchy contains foreign tables?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company