Hmm. Not sure yet which one is better here, TBH. The "ok" pattern feels a but better to me because a Datum == 0 could also be fine in some cases, be they existing of future cases, so that's more flexible by design.
I went with the "ok" model wherever possible.
When I review a patch and that I want to do a clean split, I tend to apply the whole, then remove the parts that can be split out, reapply, and then generate a diff of the previously-removed code. It's just easier to delete code. For this patch set, it would mean removing the MVC variables and related structures. It is actually not that bad based on how you have structured the restore function; there is no strong dependency between each code path treating each stxkind. This is just thinking of possible strategy if this whole thing cannot make it into the tree by the freeze deadline. Some of it may be better than nothing of it, and it is possible to add more parameters later with the right basics in place. For me, review and integration tends to be easier as a incremental set of small-ish steps, but I think that you are aware of my way of doing things :D
I've added about 30 tests covering various things that can go wrong with extended stats parameter combinations, parameter contents, expression parameter combinations.
There is one WARNING I can see that still needs coverage, but I'm at a loss as to how to set it up. It's the extended_stats.c:1202 "could not determine element type of expression" which should only happen if we have a datatype that appears to be an array but actually isn't...
Also improved documentation, moved some code to import_mcv to behave like import_expressions, etc.
