On Thu, Apr 26, 2018 at 1:08 AM, Robert Haas <[email protected]> wrote: > On Tue, Apr 24, 2018 at 6:19 AM, Amit Langote > <[email protected]> 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
