Yeah, but that problem exists no matter what. I haven't read enough of the patch to find where it's determining that, but I assume there's code in there to intuit the statistics storage type depending on the table column's data type and the statistics kind.
Correct. It borrows a lot from examine_attribute() and the *_typanalyze() functions. Actually using VacAttrStats proved problematic, but that can be revisited at some point.
We could not trust the exporting side to tell us the correct answer; for one reason, it might be different across different releases. So "derive it reliably on the destination" is really the only option.
+1
I think that it's impossible to do this in the general case, since type-specific typanalyze functions can store pretty nearly whatever they like. However, the pg_stats view isn't going to show nonstandard statistics kinds anyway, so we are going to be lossy for custom statistics kinds.