Re: Distinguish publication exclusions in object addresses

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Distinguish publication exclusions in object addresses
Date: 2026-08-07 06:11:35
Message-ID: CAHut+PsH_SC8Vw7Z=o4Bty_f4gdgoRG+4UAseyiWgAEYj+uUYg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Some review comments for v1.

======
src/backend/catalog/objectaddress.c

1.
+ {
+ "publication exclusion", OBJECT_PUBLICATION_REL
+ },

I wonder if it's better to call this "publication excluded relation".

e.g. One day there might be the ability to do "FOR ALL TABLES EXCEPT
(SCHEMA s)", but then "publication exclusion" would not know whether
you are referring to relations or schemas.

~~~

~~~

get_object_address_publication_rel:

2.
- if (!OidIsValid(address.objectId))
+ if (OidIsValid(address.objectId) &&
+ pubrel_is_exclusion == isPublicationRelationExcept(address.objectId,
+ missing_ok))
{
- if (!missing_ok)
+ *relp = relation;
+ return address;
+ }

2a.
I'm not clear on why we are passing `missing_ok` here. If the
OidIsValid(address.objectId) is true, then AFAICT the row *must* by
definition exist in the pg_publication_rel, in which case we should
never pass `missing_ok` as true.

~

2b.
Actually, I found that the isPublicationRelationExcept call in the
condition made the logic hard to understand. Can it be expanded out
and code kept more like the original? Maybe something like below?

SUGGESTION
if (!OidIsvalid(address.objectId))
{
if (!missing_ok)
{
if (pub_is_exclusion)
ereport ...
else
ereport
}
relation_close(relation, AccessShareLock);
return address;
}
else
{
/* Found row in pg_publication_rel */

/* Treat a prexcept mismatch as not found. */
if (pubrel_is_exclusion !=
isPublicationRelationExcept(address.objectId, false))
{
address.objectId = InvalidOid;
relation_close(relation, AccessShareLock);
return address;
}
}

*relp = relation;
return address;

~~~

isPublicationRelationExcept:

3.
+/*
+ * Return whether an existing pg_publication_rel entry represents a publication
+ * EXCEPT entry.
+ */
+static bool
+isPublicationRelationExcept(Oid pubreloid, bool missing_ok)

The `missing_ok` parameter means the function handles both missing and
present entries, so perhaps you don't need to say "an existing" in
that function comment.

~~~

pg_get_object_address:

4.
+ pubrel_is_exclusion = (strcmp(ttype, "publication exclusion") == 0);

Should the assignment be done later, closer to where it is used?

~~~

getObjectDescription:

5.
+ if (prform->prexcept)
+ {
+ /* translator: first %s is, e.g., "table %s" */
+ appendStringInfo(&buffer, _("exclusion of %s from publication %s"),
+ rel.data, pubname);
+ }
+ else
+ {
+ /* translator: first %s is, e.g., "table %s" */
+ appendStringInfo(&buffer, _("publication of %s in publication %s"),
+ rel.data, pubname);
+ }

I didn't find any test cases that call `pg_describe_object` and output
those "exclusion of ..." and "publication of ..." strings. Maybe there
needs to be some test like below:

------
test_pub=# SELECT
p.pubname,
pr.prrelid,
pg_describe_object('pg_publication_rel'::regclass, pr.oid, 0) AS relation,
pr.prexcept
FROM pg_publication_rel pr
JOIN pg_publication p ON p.oid = pr.prpubid
ORDER BY p.pubname, relation;
pubname | prrelid | relation | prexcept
---------+---------+---------------------------------------------+----------
pub1 | 16400 | exclusion of table t2 from publication pub1 | t
pub3 | 16397 | publication of table t1 in publication pub3 | f
(2 rows)
------

~~~

getObjectTypeDescription:

6.
- appendStringInfoString(&buffer, "publication relation");
+ if (isPublicationRelationExcept(object->objectId, missing_ok))
+ appendStringInfoString(&buffer, "publication exclusion");

Same as before. Should it be "publication excluded relation"?

======
src/test/regress/sql/publication.sql

7.
Should these tests (or some of them) be moved to "object_address.sql"?
There's already a couple of publications defined there, so it seems
reasonable there should be a 3rd publication to do FOR ALL TABLES
EXCEPT

======
Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2026-08-07 06:31:42 Re: analyze-in-stages post upgrade questions
Previous Message Koshino Taiki 2026-08-07 05:50:55 Re: Define MXID acronym in documentation