I don't object to the idea, but I don't like exposing the name "starelid". That just screams implementation artifact, and it goes against the idea that pg_stats is trying to hide the physical representation of pg_statistic. I wish we could use "tableoid", but that's taken already as a system column. Maybe "tableid" or "tablerelid"?
I went with tableid, as it pairs with tablename, and at least they're inaccurate in the same way.
Also, the proposed column ordering seems excessively random:
n.nspname AS schemaname, c.relname AS tablename, s.starelid AS starelid, a.attnum AS attnum, a.attname AS attname, stainherit AS inherited,
I could see either of these as plausible:
n.nspname AS schemaname, c.relname AS tablename, s.starelid AS tableid, a.attname AS attname, a.attnum AS attnum, stainherit AS inherited,
n.nspname AS schemaname, c.relname AS tablename, a.attname AS attname, s.starelid AS tableid, a.attnum AS attnum, stainherit AS inherited,
but I don't see the rationale behind your version.
The rationale went like this:
In order to get the grain of this table you need:
( (schemaname AND tablename) OR tableid )
AND
(attnum OR attname)
AND
inherited
As I stated earlier, I don't think there's a way to "win" with the column ordering here, any ordering we choose will look awkward to at least one use case. Your first suggestion seems fine to me, so I'm going with that one in this round.
