I had a further thought about this. What we're really talking about
here is a reference-counted TupleDesc structure: it's got no necessary
connection to TypeCacheEntry at all. And in fact there are other places
in the system that could use such a facility. For instance,
TupleTableSlot has a "shouldFreeDesc" flag that sort of allows partial,
one-way sharing of descs between slots, but it would work a lot better
if the descriptors contained reference counts instead. And it might be
worth insisting that users of a relation tupledesc from the relcache
increment its refcount while they use it --- that would get rid of some
rather shaky assumptions about when it's OK to free the tupledesc during
relcache updates.
I'm thinking it might be worth the cost to just add a refcount field to
the standard tupleDesc struct. (We don't need an isdead flag: more
elegantly, just include the TypeCacheEntry's own reference to the
tupdesc in the refcount.) Add macros IncrTupleDescRefCount and
DecrTupleDescRefCount, the latter freeing the struct if the count
goes to zero, and voila.
I'm not quite sure whether the tupledesc creation routines should
initialize the count to zero or to one, but otherwise it all seems
pretty clear. Thoughts?
regards, tom lane