On Mon, Mar 09, 2026 at 03:28:40PM -0400, Corey Huinker wrote: > Presently, I don't think we make any changes to pg_dump, unless Nathan > feels strongly that we should. If and when the need for oid-based fetching > of extended stats becomes necessary, we'll at least have a couple versions > where the catalog already had the oids handy.
That's fine with me.
-- nathan
I was sidetracked for a bit because the tests (which are accurate) seemed strange in that pg_stats_ext_exprs would have 2 rows with NULL inherited...and it took me a bit to realize that that actually makes sense because the pg_stats_ext_exprs should have one row per expression whether or not there are stats to match it. If that sounds like it could mess up vacuumdb, it actually can't, because we base those tests based off pg_stats_ext not pg_stats_ext_exprs - which does vary according to whether stats exist for the object or not. I added a comment to the regression test to that effect.
The new column expr_attnum gives the negative number that a given expression has in pg_dependencites and pg_ndistinct - as you might imagine, the number is determined by its order within the list of expressions.
If you want 0003 split into two (one for pg_stats_ext and one for pg_stats_ext_exprs) I can do that, but they felt like a package deal to me.
