Re: pg_restore handles extended statistics inconsistently with statistics data

On Thu, Jun 11, 2026 at 11:31:26AM +0800, Chao Li wrote:
> I tried the same test against 1ea44d7ddfb, the immediate predecessor
> of c32fb29e9. pg_dump dumped relation stats and attribute stats,
> while pg_restore restored nothing. So the asymmetric behavior for
> stats already existed. c32fb29e9 then added extended stats to both
> pg_dump and pg_restore, but the new EXTENDED STATISTICS DATA entries
> are handled differently from STATISTICS DATA during selective
> pg_restore, making the inconsistency visible.
>
> The asymmetric behavior was not introduced by c32fb29e9, so I think
> we probably should not change that for v19. If it's confirmed that
> this needs to be fixed and nobody else plans to work on it, I would
> be happy to add it to my TODO list for v20.

FWIW, I'm going to disagree with your argument, as I find the behavior
of v18 really weird. I would have assumed that the pg_restore
--statistics-only should restore all the stats in the schema without
the objects in the schema, relation and attribute stats (+extended,
only applies with v19), for all the objects in the schema. If you
want only the schema definition and not the objects, we already have
-s for the job.

In your example, the dump in custom format with --statistics looks
right to me: object definitions and stats. pg_dump -Fc
--statistics-only also looks right: only the stats, no objects. The
restore part is bumpy.

So I'd like to think that the behavior of the relation and attribute
stats is wrong in v18 and v19, and that the behavior of extended stats
is actually the right one in v19. Why should custom and plain formats
differ when filtering with a --schema and --statistics-only?

At the end, it seems to me that the right thing to do is the patch
attached, to-be-backpatched down to v18. check-world passes with this
patch, so we have never tested really this path, I guess? I could see
myself adding a scenario in 003, at least.

Jeff or Corey, could you comment please?
--
Michael