| 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 |
| 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 |