Re: Add starelid, attnum to pg_stats and leverage this in pg_dump

On Mon, Mar 9, 2026 at 5:04 PM Nathan Bossart <nathandbossart(at)gmail(dot)com>
wrote:

> 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.