Re: [PROPOSAL] VACUUM Progress Checker.

On Thu, Mar 10, 2016 at 6:10 AM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> So, I have looked into system_views.sql and picked up what
> catalogs/views shows objects in such way, that is, showing both
> object id and its name.
>
> Show by name: pg_policies, pg_rules, pg_tablespg_matviews,
> pg_indexes, pg_stats, pg_prepared_xacts, pg_seclabels,
> pg_stat(io)_*_tables/indexes.schemaname
> pg_stat_*_functions.schemaname
>
> Show by oid : pg_locks, pg_user_mappings.umid
>
> Both : pg_stat(io)_*_tables/indexes.relid/relname, indexrelid/indexname;
> pg_stat_activity.datid/datname, usesysid/usename
> pg_stat_activity.datid/datname, usesysid/usename
> pg_replication_slots.datoid/database
> pg_stat_database(_conflicts).datid/datname
> pg_stat_*_functions.funcid/funcname
> pg_user_mappings.srvid/srvname,umuser/usename
>
> It's surprising to see this result for me. The nature of this
> view is near to pg_stat* views so it is proper to show *both of
> database and relation* in both of oid and name.
>
> Thoughts?

I think the problem is that you can't show the name of a non-global
SQL object (such as a relation) unless the object is in the current
database. Many of the views in the first group are database-local
views, while things like pg_locks span all databases. We can show the
datid/relid always, but if we have a relname column it will have to be
NULL unless the datid is our database.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company