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

On Thu, Nov 12, 2026 at 12:10 AM Michael Paquier <michael(at)paquier(dot)xyz>
wrote:

> On Wed, Nov 11, 2026 at 11:55:08PM -0500, Corey Huinker wrote:
> > But the problem still exists on 18, and that isn't a clean backport.
> > Michael, do you want me to take that one?
>
> The only problem that can be reached is if we dump or upgrade from a
> v17 or v18 instance with the pattern of a range_empty_frac set with
> range_length_histogram as NULL, where we could perhaps switch
> range_length_histogram to '{}' under-the-hood on the dump side if a
> range_empty_frac exists. I don't want the restore functions to live
> eternally with a path authorizing for range_length_histogram=NULL if
> there is a range_empty_frac, especially now that
> range_length_histogram has to be an empty array since v19~.
>
> And the end, I have no plans to bother based on the table definition
> this requires. I could still care with something on the dump side,
> but I doubt that's worth the effort anyway. What's been done on HEAD
> and v19 is enough for these new empty-array cases. :)
> --
> Michael
>

Sorry, I should have clarified - I was considering "18 can't import
{}+empty_frac" a separate over the already-settled-not-gonna-do-it "18
can't import NULL+empty_frac" issue, but your response above indicates even
less appetite for allowing what would have to be synthetic stats just
because that's the future valid value.

I'll make the v18-specific pg_dump fix and additional patch in the other
thread.