> > > function attribute_statsitics_update() is significantly shorter. (Thank > you for a good set of tests, by the way, which sped up the refactoring > process.) >
yw > * Remind me why the new stats completely replace the new row, rather > than updating only the statistic kinds that are specified? > because: - complexity - we would then need a mechanism to then tell it to *delete* a stakind - we'd have to figure out how to reorder the remaining stakinds, or spend effort finding a matching stakind in the existing row to know to replace it - "do what analyze does" was an initial goal and as a result many test cases directly compared pg_statistic rows from an original table to an empty clone table to see if the "copy" had fidelity. > * I'm not sure what the type_is_scalar() function was doing before, > but I just removed it. If it can't find the element type, then it skips > over the kinds that require it. > that may be sufficient, > * I introduced some hard errors. These happen when it can't find the > table, or the attribute, or doesn't have permissions. I don't see any > reason to demote those to a WARNING. Even for the restore case, > analagous errors happen for COPY, etc. > I can accept that reasoning. > * I'm still sorting through some of the type info derivations. I > think we need better explanations about why it's doing exactly the > things it's doing, e.g. for tsvector and multiranges. I don't have the specifics of each, but any such cases were derived from similar behaviors in the custom typanalyze functions, and the lack of a custom typanalyze function for a given type was taken as evidence that the type was adequately handled by the default rules. I can see that this is an argument for having a second stats-specific custom typanalyze function for datatypes that need them, but I wasn't ready to go that far myself.
