With all that in mind, I am getting down to the point that we should accept that the early stages of attribute and extended stats restore should try to fetch the typcache data of the base types, then roll it around. This leads to the attached, taking care of the range, multirange and tsvector cases.
This is a good move, as it further opens the door to making stats import work with custom stakinds, but a lot of things need to happen [1][2][3] before we can even attempt that.
I'd certainly welcome more eyes here. Please note that this applies on HEAD cleanly, and should mostly apply cleanly on v19. The v18 flavor would be much more localized, of course.
It does apply cleanly to 19, and yes, the v18 is a bigger change, and will look much more like my patch unless we decide to backport statatt_get_type()...which probably isn't worth it.
[1] pg_stats needs a way to expose non-builtin stakinds
[2] pg_type needs to add an oid for typimport(), or the custom basel/elem oid and collation stuff would have to be calculated in the existing custom FOO_typanalyze()
