Re: Extended Statistics set/restore/clear functions.

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Corey Huinker <corey.huinker@gmail.com>, jian he <jian.universality@gmail.com>, Tomas Vondra <tomas@vondra.me>, pgsql-hackers@lists.postgresql.org
Date: 2025-12-05T01:19:27Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add test doing some cloning of extended statistics data

  2. Add test for pg_restore_extended_stats() with multiranges

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

  4. Include extended statistics data in pg_dump

  5. Add support for "dependencies" in pg_restore_extended_stats()

  6. Add test for MAINTAIN permission with pg_restore_extended_stats()

  7. Add pg_restore_extended_stats()

  8. Add routine to free MCVList

  9. Improve pg_clear_extended_stats() with incorrect relation/stats combination

  10. Add pg_clear_extended_stats()

  11. Introduce routines to validate and free MVNDistinct and MVDependencies

  12. Fix typo in stat_utils.c

  13. Move attribute statistics functions to stat_utils.c

  14. Improve error messages of input functions for pg_dependencies and pg_ndistinct

  15. Improve test output of extended statistics for ndistinct and dependencies

  16. Fix some compiler warnings

  17. Add input function for data type pg_dependencies

  18. Add input function for data type pg_ndistinct

  19. Rework output format of pg_dependencies

  20. Rework output format of pg_ndistinct

  21. Fix comments of output routines for pg_ndistinct and pg_dependencies

  22. Move code specific to pg_dependencies to new file

  23. Move code specific to pg_ndistinct to new file

  24. Document some structures in attribute_stats.c

  25. Fix FATAL message for invalid recovery timeline at beginning of recovery

Attachments

On Thu, Dec 04, 2025 at 07:37:32PM -0500, Tom Lane wrote:
> This of course arises because the source code is passing the address
> of a local ErrorSaveContext variable to that macro.  We don't have
> any other instances of that coding pattern AFAICS, so I wonder if
> that was really the most adapted way to do it.  Looking at the
> code, it seems to be turning around and stuffing a different error
> message into a passed-in ErrorSaveContext, which feels a little
> weird.

Thanks for the report.  Right.  There are three instances of that in
pg_dependencies.c, two in pg_ndistinct.c.  I would not mind doing the
attached to calm down these warnings, matching with the other areas of
the code, that simply removes the macro and checks the state value
directly.

> Also, I don't think these errdetail messages meet our style
> guidelines:
> 
>    errdetail("Invalid \"%s\" value.", PG_DEPENDENCIES_KEY_ATTRIBUTES));
> 
> They're supposed to be complete sentences.

Yeah, I should have been more careful here.  I have spent more time on
all of these, and adjusted all the errdetails for pg_ndistinct.c and
pg_dependencies.c to use full sentences.

I am just grouping everything with the attached.  They'd be better
if handled separately, obviously.  Comments?
--
Michael