> > That will make it *really* hard for any form of automation or drivers of > this. The information needs to go somewhere where such tools can easily > consume it, and an informational message during runtime (which is also > likely to be translated in many environments) is the exact opposite of that. >
Having given this some thought, I'd be inclined to create a view, pg_stats_missing, with the same security barrier as pg_stats, but looking for tables that lack stats on at least one column, or lack stats on an extended statistics object. Table structure would be schemaname name tablename name attnames text[] ext_stats text[] The informational message, if it changes at all, could reference this new view as the place to learn about how well the stats import went. vacuumdb might get a --missing-only option in addition to --analyze-in-stages. For that matter, we could add --analyze-missing options to pg_restore and pg_upgrade to do the mopping up themselves.
