> > 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. > Sadly true.
