Re: Extended Statistics set/restore/clear functions.

>
>
> Yes, we are entering into some complexity territory here that needs a
> very careful lookup, and I am not sure yet if your suggestion of
> input arguments is the best thing to do.
>

With that in mind, I'm going to move forward with a local static version of
statatt_get_type() which avoids the typecache stuff altogether. Whatever
remains there will be instructive for how we keep/lose/modify the real
statatt_get_type().

>
> I have been thinking about how to move this patch forward, and I think
> that we should split things a bit more the logic (aka my usual
> divide-and-conquer strategy) for the restore function, because we
> should make sure that each part is sound before merging, and that's
> also a risk reduction if we need to revert one part or the other:
> 1) One patch for ndistinct.
> 2) One patch for dependencies.
> 3) One patch for MVC.
>

All three of these are possible, though the tests of trying to set one of
the three types on a stat object incapable of holding it won't be add-able
until the next type of stats are settlable.

Expressions would be a 4th patch, and honestly it's the lion's share of the
code.

> 4) Dump/restore.
>
> The "exprs" input argument is required by all the three others, meaning
> that it needs to stand in the first bits of the patch. The order of
> ndistinct and dependencies does not matter, let's just do these based
> on the order of the input arguments. Dump/restore could be already
> integrated even if we have only 1) and 2) restore integrated in the
> tree. It also seems like the "exprs" argument should stand on top of
> all the others, as well, so it would make more sense to have it after
> "inherited" in extended_stats_argnum?
>

I think I went with the order they appeared in pg_stats_ext, with exprs
tacked on the end. I'm a bit confused why the argument order matters given
that the only user exposure is the kwargs-like interface.

>
> There are two reasons behind this set of thoughts:
> 1) The regression tests are bloated. We rely currently on one single
> extended stats object that holds all the types of stats (MCV,
> dependencies, ndistinct), meaning that for some of the valid cases we
> need to cary all the types in the input of restore function. It's
> also a bit true in terms of the invalid cases. One thing that I would
> recommend to do here is create two simpler extstat objects for each
> stxkind (one with expression, one without expression). You should
> still require the "global" extstat object that includes all the
> stxkind, which counts for the expression import path, of course.
>

We can definitely lean on the one-stat-only objects more now that we have
them.