Re: Add starelid, attnum to pg_stats and leverage this in pg_dump - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
Date
Msg-id abh63Ro7XBvik6MD@paquier.xyz
Whole thread Raw
In response to Re: Add starelid, attnum to pg_stats and leverage this in pg_dump  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
List pgsql-hackers
On Mon, Mar 16, 2026 at 03:15:14PM -0500, Nathan Bossart wrote:
> On Mon, Mar 16, 2026 at 04:04:23PM -0400, Corey Huinker wrote:
>> expr_attnum was something that Michael Paquier had lamented that the view
>> didn't have. There is obviously no present need for it, as pg_dump isn't
>> being modified for extended stats at all.
>
> Okay.  I think I'll continue to leave this one out for now.

Lamenting is the right term.  The expressions stored in an extended
stats object have attnumbers computed by the backend, starting from -1
and decremented, and we don't expose this information at all in any
system view.  It could have helped in enforcing a stronger ordering of
the items dumps for the extstats restore functions.  I still think
that it could provide an extra layer of safety.  Now, we don't
critically require it either based on how we pass down the input
arrays, how we dump the data from the catalogs, and how we treat the
order of the items given as function args.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Don't synchronously wait for already-in-progress IO in read stream
Next
From: Marco Nenciarini
Date:
Subject: Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery