Re: Distinguish publication exclusions in object addresses

Hi,

Amit asked for an example where the message says a relation is not part
of the publication while it is. Peter's example goes through the
pre-existing path; here is one inside the new code:

CREATE TABLE t2(a int);
CREATE SCHEMA s2; CREATE TABLE s2.t2(a int);
CREATE PUBLICATION pub FOR ALL TABLES EXCEPT (TABLE s2.t2);

SELECT pg_get_object_address('publication relation','{s2,t2}','{pub}');
ERROR: "t2" is not a published relation of publication "pub"

SELECT schemaname, tablename FROM pg_publication_tables
WHERE pubname = 'pub';
schemaname | tablename
------------+-----------
public | t2

So the message says that "t2" is not a published relation of pub, while
the catalog says that a t2 is. They are different tables, and the user
cannot tell which one the message is about.

Attached is a small patch on top of v5 that reports the schema too, in
the form publicationcmds.c already uses for its own messages:

errmsg("cannot use column list for relation \"%s.%s\" in
publication \"%s\"",
get_namespace_name(RelationGetNamespace(pri->relation)),
RelationGetRelationName(pri->relation), pubname)

With it:

ERROR: "s2.t2" is not a published relation of publication "pub"

It only touches the two "is not a ... relation of publication" messages,
which are the ones reached when the relation does have an entry. The
"does not exist" messages, including the new one for excluded relations
in v5, keep the unqualified form of the existing message they sit next
to. `make check` passes with v5 plus this patch; publication.out is
updated for the two messages.

On the rest of the patch: I applied v4 to master at 04c4c1c3a96, built
with --enable-cassert and exercised the new object type by hand. All
239 tests pass, pg_identify_object_as_address() reports "publication
excluded relation", the identify/address round trip works, and
pg_describe_object() gives "exclusion of table t2 from publication pub".
Asking for the wrong kind is rejected as intended, in both directions.
I did not find a functional problem. v5 applies cleanly on the same
commit and passes as well.

Separately, I will start the thread shveta suggested for the case Peter
ran into with FOR ALL TABLES. I have a patch for it that adds a detail
only when the table really is published, and I measured that it also
reproduces back to 13.

Regards,
Manu

El mié, 16 sept 2026 a las 5:57, vignesh C (<vignesh21(at)gmail(dot)com>) escribió:
>
> On Wed, 16 Sept 2026 at 13:57, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> >
> > I don’t think the fix would add much complexity, please see the attached diff I tried. This error message is shown to users, so I think improving it is worthwhile.
>
> Agreed. I had initially thought the additional code complexity was not
> worthwhile. Since this is a user-facing error message, I agree that
> making it more specific is worthwhile. Thanks, I have merged the
> changes.
> The attached v5 version patch has the changes for the same.
>
> Regards,
> Vignesh