On Tue, Feb 24, 2026 at 08:45:26AM -0500, Corey Huinker wrote: > 1. The view would need to expose pg_class.oid so that it could be joined to > the listed_object CTE. Our pattern seems to be schemaname+tablename with no > exposed oids, something that has caused a problem in the past, namely in > pg_dump when batching attribute stats. Is exposing oids in these views a > no-no?
I don't think so. Counterexamples include pg_stat_activity, pg_stat_subscription, pg_stat_database, pg_stat_all_tables, and more. If anything, maybe we should consider _adding_ oid columns to views like pg_stats_ext... > 2. The view either needs the pg_class.oid to join back to pg_class to get > relkind, relpersistence, relfrozenxid, relminmxid, etc...or it needs to > expose those columns as a part of the view, which would be problematic when > vacuumdb and other apps decide that they need to filter on some other part > of pg_class, and then we've got different versions of the system view which > makes that option highly unattractive. Hm. I don't know how much to worry about this. System view/catalog changes do happen from time to time, so unless we have a bunch of possible changes that will happen soon, I'd expect it to probably be okay. > If we instead did a system function `pg_rel_is_missing_stats(oid) returns > boolean`, but it would still need to sanity check on relkind and filter on > relpersistence and inherited. Couldn't the function handle those sanity checks? -- nathan
