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

From Tom Lane
Subject Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
Date
Msg-id 732107.1772138167@sss.pgh.pa.us
Whole thread Raw
In response to Add starelid, attnum to pg_stats and leverage this in pg_dump  (Corey Huinker <corey.huinker@gmail.com>)
Responses Re: Add starelid, attnum to pg_stats and leverage this in pg_dump
List pgsql-hackers
Corey Huinker <corey.huinker@gmail.com> writes:
> Per side conversation in [1], this patch exposes pg_statistic.starelid in
> the pg_stats view (0001) and then changes pg_dump to use the starelid in
> the queries on pg_stats rather than the combination of schemaname+relname,

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"?

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Matheus Alcantara"
Date:
Subject: Re: Show expression of virtual columns in error messages
Next
From: Peter Eisentraut
Date:
Subject: Unicode update and some tooling improvements