Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange
Date
Msg-id arW2T9Oa5k6Wpq-O@paquier.xyz
Whole thread
In response to Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange
Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange
List pgsql-bugs
On Fri, Sep 25, 2026 at 07:52:07AM +0900, Michael Paquier wrote:
> Yes, I was wondering about that a bit, feeding a single typcache entry
> across the board.  And while looking at the code, I was reminded about
> the following exceptions:
> extended_stats_funcs.c: if (typid == TSVECTOROID)
> stat_utils.c:   if (*atttypid == TSVECTOROID)
> stat_utils.c:   if (atttypid == TSVECTOROID)
>
> I think that the existing code is also broken when defining a domain
> over tsvector if we don't feed a domain base type in these three
> spots.

With all that in mind, I am getting down to the point that we should
accept that the early stages of attribute and extended stats restore
should try to fetch the typcache data of the base types, then roll it
around.  This leads to the attached, taking care of the range,
multirange and tsvector cases.

I'd certainly welcome more eyes here.  Please note that this applies
on HEAD cleanly, and should mostly apply cleanly on v19.  The v18
flavor would be much more localized, of course.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #19715: pg_restore_attribute_stats() rejects range statistics for a domain over int4multirange
Next
From: Masahiko Sawada
Date:
Subject: Re: autovacuum: automatically propagate updated parameters