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

From Corey Huinker
Subject Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
Date
Msg-id CADkLM=d=udo8pxPeLQA6Z2YKLMgTvJM_Uh2mYtsCE38fJ8xodw@mail.gmail.com
Whole thread
In response to Re: Add starelid, attnum to pg_stats and leverage this in pg_dump  (Sami Imseih <samimseih@gmail.com>)
Responses Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
List pgsql-hackers
>> "pg_stats.relation" with a description of "Name of table or index" is
>> more appropriate.
>> It is a change that we can possibly make in a major version. Looked
>> through the archives,
>> and did not see this being reported/discussed.
>
>
> I don't see it changing in any version, minor or major.

This could be a separate discussion as it's not the fault of this patch,
but clearly "tablename" is not correct here.

Certainly up for debate, but changing it would break existing scripts, and that's generally a non-starter around here.
 
I noticed that you changed the tests to selecting individual columns. I am
not clear as to why this is better?

-SELECT *
+SELECT schemaname, tablename, attname, attnum, inherited, null_frac, avg_width,
+    n_distinct, most_common_vals, most_common_freqs, histogram_bounds,
+    correlation, most_common_elems, most_common_elem_freqs,
+    elem_count_histogram, range_length_histogram, range_empty_frac,
+    range_bounds_histogram

Well, the oid is now a part of the view, and that's not stable from one regression run to the next, so we have to exclude it.

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Why clearing the VM doesn't require registering vm buffer in wal record
Next
From: Sami Imseih
Date:
Subject: Re: Add starelid, attnum to pg_stats and leverage this in pg_dump