This should also lead to better error messages on restore depending on the expression data we expect (I'll check ANALYZE about the possibility of partial generation of the expression stats data tomorrow or so).
compute_expr_stats() is a bit confusing. There's a tcnt counter that looks like it was meant to be independent of the loop variable, but currently there are no ways to skip setting the datum at the tnct index and then incrementing tcnt. I checked the history, and it's like that all the way back to the introduction of expression stats in a4d75c86bf1522.
> But in a way we're already getting this type checking if the expressions > have different datatypes and either of them have most_common_values, > histogram_bounds, or most_common_elems - as all of those require input > coersion of the array values to datatypes of the expressions, and any > failure in any of those dooms the whole exprs array.
Yeah, but that does not help if two expressions use the same types, which is possible. On the contrary, that sounds kind of confusing to rely on for this portion of the statext data to restore.
I wouldn't suggest relying on it, but our test cases do currently have multi-expression stats, and if the order of them was getting jumbled due to parallel query or something we'd be getting intermittent failures.
Anyway, I added AttrNumber exprnum to the errhint() on the errors encountered in import_expressions, all EXCEPT for the ones in statatt_build_stavalues, as the error messages there are localized to the array values being imported, and I'm not sure how to append an errhint() to an already existing error_data before rethrowing it.
