pgsql: Clean up the behavior and API of catalog.c'sis-catalog-relation - Mailing list pgsql-committers

From Tom Lane
Subject pgsql: Clean up the behavior and API of catalog.c'sis-catalog-relation
Date
Msg-id E1hOZix-0005su-5L@gemulon.postgresql.org
Whole thread Raw
List pgsql-committers
Clean up the behavior and API of catalog.c's is-catalog-relation tests.

The right way for IsCatalogRelation/Class to behave is to return true
for OIDs less than FirstBootstrapObjectId (not FirstNormalObjectId),
without any of the ad-hoc fooling around with schema membership.

The previous code was wrong because (1) it claimed that
information_schema tables were not catalog relations but their toast
tables were, which is silly; and (2) if you dropped and recreated
information_schema, which is a supported operation, the behavior
changed.  That's even sillier.  With this definition, "catalog
relations" are exactly the ones traceable to the postgres.bki data,
which seems like what we want.

With this simplification, we don't actually need access to the pg_class
tuple to identify a catalog relation; we only need its OID.  Hence,
replace IsCatalogClass with "IsCatalogRelationOid(oid)".  But keep
IsCatalogRelation as a convenience function.

This allows fixing some arguably-wrong semantics in contrib/sepgsql and
ReindexRelationConcurrently, which were using an IsSystemNamespace test
where what they really should be using is IsCatalogRelationOid.  The
previous coding failed to protect toast tables of system catalogs, and
also was not on board with the general principle that user-created tables
do not become catalogs just by virtue of being renamed into pg_catalog.
We can also get rid of a messy hack in ReindexMultipleTables.

While we're at it, also rename IsSystemNamespace to IsCatalogNamespace,
because the previous name invited confusion with the more expansive
semantics used by IsSystemRelation/Class.

Also improve the comments in catalog.c.

There are a few remaining places in replication-related code that are
special-casing OIDs below FirstNormalObjectId.  I'm inclined to think
those are wrong too, and if there should be any special case it should
just extend to FirstBootstrapObjectId.  But first we need to debate
whether a FOR ALL TABLES publication should include information_schema.

Discussion: https://postgr.es/m/21697.1557092753@sss.pgh.pa.us
Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/2d7d946cd323ce1c1d3f3ef0e5f2f41591afc1b9

Modified Files
--------------
contrib/sepgsql/dml.c                |   8 ++-
src/backend/access/transam/varsup.c  |   2 +-
src/backend/catalog/catalog.c        | 102 ++++++++++++++++++++---------------
src/backend/catalog/heap.c           |   2 +-
src/backend/catalog/pg_publication.c |   8 +--
src/backend/commands/indexcmds.c     |  12 ++---
src/backend/commands/tablecmds.c     |   5 +-
src/backend/utils/cache/relcache.c   |   4 +-
src/include/catalog/catalog.h        |   5 +-
9 files changed, 81 insertions(+), 67 deletions(-)


pgsql-committers by date:

Previous
From: Michael Paquier
Date:
Subject: pgsql: Fix error status of vacuumdb when multiple jobs are used
Next
From: Peter Eisentraut
Date:
Subject: pgsql: Fix grammar in error message