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

From Nathan Bossart
Subject Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
Date
Msg-id abhXqx-xffsknv3B@nathan
Whole thread Raw
In response to Re: Add starelid, attnum to pg_stats and leverage this in pg_dump  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
List pgsql-hackers
On Sat, Mar 14, 2026 at 05:13:19PM -0400, Corey Huinker wrote:
> "_stable", nice name choice. Rebasing was nonzero but just barely.

Thanks.  Here is what I have staged for commit for the next patch in the
series.

>  CREATE VIEW pg_stats WITH (security_barrier) AS
>      SELECT
> -        nspname AS schemaname,
> -        relname AS tablename,
> -        attname AS attname,
> +        n.nspname AS schemaname,
> +        c.relname AS tablename,
> +        a.attrelid AS tableid,
> +        a.attname AS attname,
> +        a.attnum AS attnum,

I didn't see why we needed to change the lines for the existing columns, so
I left those parts out.

>  CREATE VIEW pg_stats_ext WITH (security_barrier) AS
>      SELECT cn.nspname AS schemaname,
>             c.relname AS tablename,
> +           s.stxrelid AS tableid,
>             sn.nspname AS statistics_schemaname,
>             s.stxname AS statistics_name,
> +           s.oid AS statid,

I went with "statistics_id" to match the naming scheme.

>  CREATE VIEW pg_stats_ext_exprs WITH (security_barrier) AS
>      SELECT cn.nspname AS schemaname,
>             c.relname AS tablename,
> +           s.stxrelid AS tableid,
>             sn.nspname AS statistics_schemaname,
>             s.stxname AS statistics_name,
> +           s.oid AS statid,
>             pg_get_userbyid(s.stxowner) AS statistics_owner,
> -           stat.expr,
> +           expr.expr,
> +           0 - expr.ordinality AS expr_attnum,

I left the expr_attnum stuff out.  It seems to make this patch quite large
and complicated, we don't plan to use it for the pg_dump patch, and I'm not
sure about showing users a "synthetic attnum" that seems to have no other
point of reference.  Would this information be useful in pg_dump somewhere?
I'm curious to hear more about the intent.

>  CREATE VIEW stats_import.pg_stats_stable AS
> -  SELECT schemaname, tablename, attname, inherited, null_frac, avg_width,
> +  SELECT schemaname, tablename, attname, attnum, inherited, null_frac, avg_width,

I didn't see much value in adding attnum here given the size of the changes
to the expected output it produces.

> +       <structfield>tableid</structfield> <type>oid</type>
> +       (references <link
linkend="catalog-pg-attribute"><structname>pg_attribute</structname></link>.<structfield>attrelid</structfield>)

While we might be pulling the OID from pg_attribute in the view, we seem to
point to the true origin for these reference notes elsewhere, so I changed
it to pg_class.oid here.

> +       <structfield>tableid</structfield> <type>oid</type>
> +       (references <link
linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>.<structfield>stxrelid</structfield>)

... and here.

> +       <structfield>tableid</structfield> <type>oid</type>
> +       (references <link
linkend="catalog-pg-statistic-ext"><structname>pg_statistic_ext</structname></link>.<structfield>stxrelid</structfield>)

... and here.

-- 
nathan

Attachment

pgsql-hackers by date:

Previous
From: Matt Blewitt
Date:
Subject: Re: [PATCH] Fix JSON_SERIALIZE() coercion placeholder type for jsonb input
Next
From: Matthias van de Meent
Date:
Subject: Re: Adding REPACK [concurrently]