On Thu, Sep 24, 2026 at 12:22 AM Michael Paquier <michael@paquier.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.
