Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange

>
> 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()
[3] pg_dump needs to be made aware of this