pgsql: Clean up the behavior and API of catalog.c's is-catalog-relation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Clean up the behavior and API of catalog.c's is-catalog-relation
Date: 2019-05-09 03:27:59
Message-ID: E1hOZix-0005su-5L@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2019-05-09 06:52:32 Re: pgsql: Add strict_multi_assignment and too_many_rows plpgsql checks
Previous Message Michael Paquier 2019-05-09 01:32:02 pgsql: Fix error status of vacuumdb when multiple jobs are used