At Tue, 26 Jul 2016 13:51:53 +0900, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote in <f8f2a32e-46da-d34d-cabc-24e75d6da...@lab.ntt.co.jp> > > So, how about splitting the original equalTupleDescs into > > equalTupleDescs and equalTupleConstraints ? > > Actually TupleConstr is *part* of the TupleDesc struct, which the > relcache.c tries to preserve in *whole* across a relcache flush, so it > seems perhaps cleaner to keep the decision centralized in one function:
The "Logical" is the cause of the ambiguity. It could be thought that relation cache maintains "Physical" tuple descriptor, which is defferent from "Logical" one. > keep_tupdesc = equalTupleDescs(relation->rd_att, newrel->rd_att); > ... > /* preserve old tupledesc and rules if no logical change */ > if (keep_tupdesc) > SWAPFIELD(TupleDesc, rd_att); > > Also: > > /* > * This struct is passed around within the backend to describe the > * structure of tuples. For tuples coming from on-disk relations, the > * information is collected from the pg_attribute, pg_attrdef, and > * pg_constraint catalogs. > ... > typedef struct tupleDesc > { > > It would perhaps have been clear if there was a rd_constr field that > relcache.c independently managed. > > OTOH, I tend to agree that other places don't quite need the whole thing > (given also that most other callers except acquire_inherit_sample_rows > compare transient row types) Yes, constraints apparently doesn't affect the shpae of generatred tuples. On the other hand relcache should be aware of changes of constraints. Furthermore the transient row types has utterly no relation with constraints of even underlying relations. So, almost as your proposition, what do you think if the equalTupleDescs has extra parameter but named "logical", and ignore constraints if it is true? (Obviously the opposite will do). What I felt uneasy about is the name "compare_constr". regards, -- Kyotaro Horiguchi NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers