Re: Add expressions to pg_restore_extended_stats()

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Corey Huinker <corey.huinker@gmail.com>
Cc: Chao Li <li.evan.chao@gmail.com>, Tender Wang <tndrwang@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas@vondra.me>
Date: 2026-03-03T05:36:50Z
Lists: pgsql-hackers
On Tue, Feb 10, 2026 at 12:56:51PM +0900, Michael Paquier wrote:
> This is very slightly embarrassing.  Compilation was warning here,
> just missed it.  Thanks.

With 3b7a6fa15720 applied, taking care of the logical holes found
while reviewing this feature, I have looked again at this patch.

The patch has been stable in the last month, still I have spent a lot
of time torturing it in the last two days, mainly cross-checking the
input parameters, playing with a lot of injection, and found a few
holes while analyzing the code.

Here are my notes:  
- The pg_dump query was broken for the three range fields added to
pg_stats_ext_exprs in v19.  This has to be broken out in three parts:
one for inherited, one for the range fields, and the rest.
- One weird case I have been pondering about is a pre-v18 -> v19 case
with a range type, as the dump would not include the three range
fields in the data restore.  At the end, rather than expecting a dump
and/or upgrade to test this scenario, I have added a SQL test that
emulates the same, at the end of stats_import.sql.  That may feel
overkill, but this is dealing with a partial input, that we have to
authorize when restoring the numbers.
- The code forgot to check that if one of the three
"range_length_histogram", "range_empty_frac", or
"range_bounds_histogram" is set, the two others have to be set.
- The code forgot to check that a typtype of TYPTYPE_RANGE or
TYPTYPE_MULTIRANGE is required when passing in input the range_*
fields, like attributes.  I was able to insert buggy data in the
catalogs with that.
- Some quote_literal in error messages, not wanted, with incorrect
quoting.

All that has been rather easy to fix at the end, so I have applied the
result.  It should mean that ANALYZE is not required now after
pg_upgrade.  The case of the three range_* fields feels annoying as we
lacked them until v19, meaning that we cannot restore them when
upgrading from a v14~v18 cluster.  At least there is all the
infrastructure in place for them moving forward.

Anything else missing?
--
Michael

Commits

  1. Refactor tests for catalog diff comparisons in stats_import.sql

  2. Fix typo in stats_import.sql

  3. Add support for "exprs" in pg_restore_extended_stats()

  4. Add information about range type stats to pg_stats_ext_exprs

  5. Fix comment in extended_stats_funcs.c