| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org, 125atishprak(at)gmail(dot)com |
| Subject: | Re: BUG #19857: Stats restore rejects empty arrays, losing range and array stats |
| Date: | 2026-11-12 01:32:34 |
| Message-ID: | avUXMh93q1MifJwq@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, Nov 12, 2026 at 10:26:00AM +0900, Michael Paquier wrote:
> I cannot really get excited to allow this combination in the restore
> functions, though, as it means being more lenient on
> range_length_histogram forever, and the v19~ decision of using an
> empty array is much better to me in the long term. An extra argument
> is that this case is super narrow anyway, unlikely to be hit in
> practice? As far as I can see, you need a [multi]range column with
> less than *2* non-empty values..
Or we could do something on the dump side, forcing an empty array out
if seeing a NULL range_length_histogram.. Still not sure if that's
worth bothering, just saying.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-11-12 01:34:36 | Re: BUG #19842: pg_restore_extended_stats() rejects a faithful pg_dump of ANALYZE-produced range expression statisti |
| Previous Message | Michael Paquier | 2026-11-12 01:26:00 | Re: BUG #19857: Stats restore rejects empty arrays, losing range and array stats |