Re: Distinguish publication exclusions in object addresses

On Wed, 16 Sept 2026 at 18:12, Manuel Reyes Bravo
<manuelreyesbravo(at)gmail(dot)com> wrote:
>
> Zhijie is right that my own example was weak: the schema was right there
> in the call. Your example is the one that matters, and it goes through
> the "does not exist" message, which my first delta did not touch. The
> attached 0001 now qualifies all four errors in
> get_object_address_publication_rel(), so that case reads:
>
> ERROR: publication relation "s2.t2" in publication "pub" does not exist
>
> > If at all we plan to add it, it will be good to use
> > 'RelationGetQualifiedRelationName' instead.
>
> I tried it first, and it quotes the name twice when it needs quoting,
> because it goes through quote_qualified_identifier() and these messages
> already put the name in quotes:
>
> ERROR: publication relation ""Sales Q3"."Big Table"" in
> publication "pub" does not exist
>
> So 0001 uses "\"%s.%s\"" with get_namespace_name(), which is the form of
> 55 errmsg() calls in src/backend, against 3 that put a quoted qualified
> name inside quotes.

Thanks, Manu, for the patches. I think it would be better to start a
new thread to discuss this and the other functions listed by Hou-san
at [1]. Since all of the get_XXX functions handle this in a similar
way, we can discuss them together and ensure that the changes are
applied consistently.
get_relation_by_qualified_name
get_object_address_attribute
get_object_address_attrdef
get_object_address_unqualified
get_object_address_type
...

> That also shows the same problem in commit a49b9cfd72d, which is in
> REL_19_STABLE:
>
> CREATE TABLE "testpub Part2" PARTITION OF testpub_root FOR VALUES
> FROM (100) TO (200);
> CREATE PUBLICATION testpub9 FOR ALL TABLES EXCEPT (TABLE "testpub Part2");
> ERROR: cannot specify relation "public."testpub Part2"" in the
> publication EXCEPT clause
>
> 0002 fixes it by building the name the same way, without changing the
> message text, and adds that case to publication.sql. Without the fix
> the new test fails with the output above; with it, it passes. 0002 does
> not depend on v5 and applies to both master and REL_19_STABLE.
>
> Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > There is no harm, but it is not consistent with the other object
> > messages used here (e.g., they do not report schema-qualified names):
>
> That is true of objectaddress.c: none of its messages qualifies the name
> today. The case for doing it here is the one a49b9cfd72d made for the
> EXCEPT errors, that the same name can exist in several schemas, plus
> shveta's search_path example. Whether that outweighs consistency with
> the rest of objectaddress.c is Amit's call; if not, 0001 can simply be
> dropped, and 0002 still stands on its own.

Please have a look at the discussion regarding the commit in [1]
thread. If you still feel that it needs further discussion, we can
continue discussing your suggestion in the thread at [2], as it is not
directly related to the topic of this current thread.

[1] - https://www.postgresql.org/message-id/TY4PR01MB17718424B75122A8D12257A5694B92%40TY4PR01MB17718.jpnprd01.prod.outlook.com
[2] - https://www.postgresql.org/message-id/flat/CAFiTN-scG7b11Jsp%2BVoDRT8ZFE84eSKLcDsSB18dZ8AaP%3DR-mw%40mail.gmail.com

Regards,
Vignesh