Re: minor fix for acquire_inherited_sample_rows

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