Improve commentary about hack in is_publishable_class().

The FirstNormalObjectId test here is a kluge that needs to go away,
but the only substitute we can think of is to add a column to pg_class,
which will take more work than can be handled right now.  Add some
commentary in the meanwhile.

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

diff --git a/src/backend/catalog/pg_publication.c b/src/backend/catalog/pg_publication.c
index be0a7e7390a69a924bb005d692a8dcecb12d6d96..f8475c1aba209eec6f554b482acf90b68d63447c 100644 (file)
--- a/src/backend/catalog/pg_publication.c
+++ b/src/backend/catalog/pg_publication.c
@@ -91,12 +91,17 @@ check_publication_add_relation(Relation targetrel)
  * Does same checks as the above, but does not need relation to be opened
  * and also does not throw errors.
  *
- * Note this also excludes all tables with relid < FirstNormalObjectId,
+ * XXX  This also excludes all tables with relid < FirstNormalObjectId,
  * ie all tables created during initdb.  This mainly affects the preinstalled
- * information_schema.  (IsCatalogRelationOid() only excludes tables with
- * relid < FirstBootstrapObjectId, making that test rather redundant, but
- * really we should get rid of the FirstNormalObjectId test not
- * IsCatalogRelationOid.)
+ * information_schema.  IsCatalogRelationOid() only excludes tables with
+ * relid < FirstBootstrapObjectId, making that test rather redundant,
+ * but really we should get rid of the FirstNormalObjectId test not
+ * IsCatalogRelationOid.  We can't do so today because we don't want
+ * information_schema tables to be considered publishable; but this test
+ * is really inadequate for that, since the information_schema could be
+ * dropped and reloaded and then it'll be considered publishable.  The best
+ * long-term solution may be to add a "relispublishable" bool to pg_class,
+ * and depend on that instead of OID checks.
  */
 static bool
 is_publishable_class(Oid relid, Form_pg_class reltuple)