Re: BUG #19842: pg_restore_extended_stats() rejects a faithful pg_dump of ANALYZE-produced range expression statisti

From: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: 303677365(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19842: pg_restore_extended_stats() rejects a faithful pg_dump of ANALYZE-produced range expression statisti
Date: 2026-11-13 16:07:17
Message-ID: CADkLM=d7Aw5Kevni221A71Tp29+Jx2S_KaX9=ig_911WjYOrCQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

>
> 0001 and 0003 were by far the most urgent items to handle for v19 (and
> actually the less risky ones). Without 0002 for the moment, it still
> means that we could miss some stats at dump/restore due to the
> NULL/empty change introduced in v19 when upgrading from v17/18, but at
> least we are clear for any future moves, or when doing a dump from
> v19.

I agree with your prioritization - 0002 can wait a bit.

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message Amit Langote 2026-11-13 13:28:32 Re: BUG #19851: Adding a tautological CHECK(true) to a domain changes JSON_VALUE's result (silent NULL, value/type c