At Tue, 26 Jul 2016 13:51:53 +0900, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> wrote in
<f8f2a32e-46da-d34d-cabc-24e75d6da082@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