I wrote:
> I think this is committable --- how about you?
... or not. I just noticed that the typcache tracks each type's
typstorage setting, and there's no provision for flushing/reloading
that.
As far as I can find, there is only one place where the cached
value is used, and that's in rangetypes.c which needs to know
whether the range element type is toastable. (It doesn't actually
need to know the exact value of typstorage, only whether it is or
isn't PLAIN.)
We have a number of possible fixes for that:
1. Upgrade typcache.c to support flushing and rebuilding this data.
That seems fairly expensive; while we may be forced into that someday,
I'm hesitant to do it for a fairly marginal feature like this one.
2. Stop using the typcache for this particular purpose in rangetypes.c.
That seems rather undesirable from a performance standpoint, too.
3. Drop the ability for ALTER TYPE to promote from PLAIN to not-PLAIN
typstorage, and adjust the typcache so that it only remembers boolean
toastability not the specific toasting strategy. Then the cache is
still immutable so no need for update logic.
I'm kind of liking #3, ugly as it sounds, because I'm not sure how
much of a use-case there is for the upgrade-from-PLAIN case.
Particularly now that TOAST is so ingrained in the system, it seems
rather unlikely that a production-grade data type wouldn't have
been designed to be toastable from the beginning, if there could be
any advantage to that. Either #1 or #2 seem like mighty high prices
to pay for offering an option that might have no real-world uses.
regards, tom lane
