On Thu, Apr 26, 2018 at 1:08 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Apr 24, 2018 at 6:19 AM, Amit Langote
> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>> Given what equalTupleDescs was invented for (commit a152ebeec), reducing
>> it down to what can be sensibly used for checking whether tuple conversion
>> is needed between a parent and child will, I'm afraid, make it useless for
>> its original purpose. Just looking at a few checks that are now in it,
>> for example:
>>
>> for (i = 0; i < tupdesc1->natts; i++)
>> {
>> Form_pg_attribute attr1 = TupleDescAttr(tupdesc1, i);
>> Form_pg_attribute attr2 = TupleDescAttr(tupdesc2, i);
>>
>> <...snip...>
>>
>> if (attr1->attislocal != attr2->attislocal)
>> return false;
>> if (attr1->attinhcount != attr2->attinhcount)
>> return false;
>> <...snip...>
>> /* attacl, attoptions and attfdwoptions are not even present... */
>> }
>>
>> attislocal and attinhcount obviously can't be same for parent and a child.
>> Also, the comment above seems to assume that this function is being
>> called from the only place it was designed for (RelationClearRelation).
>
> +1. I think we're really abusing equalTupleDescs() for purposes for
> which it was not invented. Instead of changing it, let's invent a new
> function that tests for the thing partitioning cares about (same
> ordering of the same columns with the same type information) and call
> it logicallyEqualTupleDescs() or something like that.
Why don't we just rely on the output of convert_tuples_by_name(),
which it seems is always called right now? What's advantage of adding
another tuple descriptor comparison?
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company