Re: minor fix for acquire_inherited_sample_rows

On Tue, Apr 24, 2018 at 6:19 AM, Amit Langote
<Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)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