CRDB's pg_catalog tables do not properly correspond to PostgreSQL system catalogs

[ericharmeling]

Describe the problem

#60758 introduced a number of new tables to the pg_catalog virtual schema. Most of the tables introduced in that PR neither correspond to a table in pg_catalog, nor to one of the system views listed on the official PostgreSQL documentation page on system catalogs. It appears to be that case that most of the tables introduced in that PR are a mixed bag of lightly-documented system views and indexes, from all over the PostgreSQL system (e.g., "Statistics Collector" views).

I've made a document to track the differences among the official PostgreSQL system catalog (which includes system views), the tables in pg_catalog in PostgreSQL 13 (which does not include system views), the tables in pg_catalog in CockroachDB 20.2.5, and the tables added to CockroachDB in #60758: https://docs.google.com/spreadsheets/d/1azfgQJQJriUii1dd8_RwhgHBqhlrwkjao1rISR8YAOc/edit#gid=1321389238

Expected behavior

If the goal is to achieve parity between pg_catalog in PostgreSQL and pg_catalog in CockroachDB, then the tables should be identical between the two. That is not the case (and has never been the case).

If the goal is to achieve parity between the official system catalogs in PostgreSQL and pg_catalog in CockroachDB, then the tables in the CRDB pg_catalog should correspond to the system catalogs listed in the PostgreSQL documentation, which include all of the tables in pg_catalog in PostgreSQL, in addition to a set of system views. This goal is more aligned with the 20.2 state of the CRDB pg_catalog.

If there is some other goal (i.e., to support as many PostgreSQL system tables, views, sequences, etc. as possible), then there might be a better place to put those objects than pg_catalog, if there is not a direct PostgreSQL equivalent in the PostgreSQL pg_catalog or the official PostgreSQL system catalog.

[ericharmeling]

@RichardJCai

[RichardJCai]

Closed via #61876