On Wed, 16 Sept 2026 at 18:12, Manuel Reyes Bravo <[email protected]> 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) <[email protected]> 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
