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.
