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

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Sami Imseih <samimseih(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
Date: 2026-03-16 22:52:38
Message-ID: abiJtpb6FsluRpGk@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 17, 2026 at 06:49:17AM +0900, Michael Paquier wrote:
> 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.

FTR I'm not mortally opposed to the idea. I just want to get the easier
stuff out of the way first so we can commit the pg_dump change. Then we
can give expr_attnum our undivided attention.

--
nathan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2026-03-16 22:57:57 Re: tablecmds: reject CLUSTER ON for partitioned tables earlier
Previous Message Tomas Vondra 2026-03-16 22:50:28 Re: pg_stat_io_histogram