Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange

On Thu, Sep 24, 2026 at 1:56 AM Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
wrote:

>
>
> On Thu, Sep 24, 2026 at 12:22 AM Michael Paquier <michael(at)paquier(dot)xyz>
> wrote:
>
>> On Wed, Sep 23, 2026 at 03:02:30PM -0400, Corey Huinker wrote:
>> > I'm looking into this.
>>
>> I have begun looking at this before you had sent this reply, and we
>> are handling the base type of a domain in an incorrect way, assuming
>> that for attribute and extended stats we should just always check for
>> TYPTYPE_[MULTI]RANGE, but domains don't map with that at all. I think
>> that we are missing an extra getBaseType(), like
>> [multi]range_typanalyze(), where we use a [multi]range_get_typcache()
>> to cope with domains (getBaseTypeAndTypmod() does the job in the
>> typcache). That's also mentioned in the code.
>>
>> And the same can be said for expressions in extended stats where a
>> domain that has a [multi]range type is involved. We would be better
>> getting rid of these hardcoded TYPTYPE values, IMO.
>>
>> Spoiler: the tests are boring, still required. And fortunately, the
>> only damage is stats data not restored but skipped. Annoying, but not
>> as annoying as in the class of problems labelled like "I corrupt the
>> catalogs".
>>
>> What do you think?
>> --
>> Michael
>>
>
> Here's what I was just about to post to the list, only to see that you
> already posted something.
>
> Will begin reviewing yours immediately.
>

So it seems we came to the very similar conclusions.

I had a plan to add something like statatt_get_range_type() as a follow-up
patch, but wanted to get the fix working first.

As for test cases, mine are based on the existing "are foo_clone stats a
faithful copy of foo stats" tests, rather than hardcoding stats. My way
feels more future proof, but the future in which the hardcoded way breaks
is a long way off.

Similarly, after adding those foo->foo_clone tests, it seemed like the
regression test could stand to have helper functions for restore stats from
object a into object a_clone, but that too was for a follow-up patch as I
didn't want to distract from the fix itself.

The additional test cases for trying to cram range stats into non-range
attributes appear correct and necessary.

Overall, it's a +1 from me.