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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
Cc: imchifan(at)163(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange
Date: 2026-09-24 04:22:10
Message-ID: arSlchrpWvs8m8M2@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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

Attachment Content-Type Size
0001-Fix-import-of-statistics-for-domains-over-multi-rang.patch text/plain 24.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Nikolay Samokhvalov 2026-09-24 04:44:54 Re: autovacuum: automatically propagate updated parameters
Previous Message Ayush Tiwari 2026-09-24 02:47:10 Re: BUG #19687: ALTER SEQUENCE provokes error XX001 could not read blocks