Re: BUG #19857: Stats restore rejects empty arrays, losing range and array stats

On Thu, Nov 12, 2026 at 07:40:47AM +0900, Michael Paquier wrote:
> Yeah, I intend to wrap this one this morning.

Applied this down to v19, to match with the empty array cases that
have been introduced in 261f89a976b.

I think that this leaves an extra case, though... In v17 and v18, it
is possible for range_empty_frac to be stored with
range_length_histogram as NULL. On v19 and HEAD,
range_length_histogram is an empty array, so the two are always set.
The restore functions require the two together when upgrading to 18~,
meaning that some stats values could be lost when upgrading/dumping
the stats from a v17 or v18.

That's one pattern that Atish was mentioning originally in his report,
even if I got a bit lost in my mind due to the dump/upgrade mentions
with v19 and HEAD.

I cannot really get excited to allow this combination in the restore
functions, though, as it means being more lenient on
range_length_histogram forever, and the v19~ decision of using an
empty array is much better to me in the long term. An extra argument
is that this case is super narrow anyway, unlikely to be hit in
practice? As far as I can see, you need a [multi]range column with
less than *2* non-empty values..

I agree that we should move on with fixing the extstats restore
functions, of course, in terms of the handling of the empty array
values, to map now with what the attribute restores are able to do.
And fix this second issue down to v19. Let's do that on the other
thread, we are done here for me.
--
Michael