Re: minor fix for acquire_inherited_sample_rows

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.

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