Re: Include schema-qualified names in publication error messages. - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Include schema-qualified names in publication error messages.
Date
Msg-id CAFiTN-sChBLdjy1oWgeHpTYj2UuCLLG9vcqEW+h+ONio_8mUBA@mail.gmail.com
Whole thread
In response to Re: Include schema-qualified names in publication error messages.  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: Include schema-qualified names in publication error messages.
List pgsql-hackers
On Wed, Apr 29, 2026 at 9:28 AM Peter Smith <smithpb2250@gmail.com> wrote:
>
> On Tue, Apr 28, 2026 at 9:39 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Tue, Apr 28, 2026 at 4:34 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > >
> > > Previously, error messages in check_publication_add_relation() only
> > > reported the relation name when a table could not be added to a
> > > publication or included in an EXCEPT clause. This could be ambiguous
> > > in databases where the same relation name exists in multiple schemas.
> > >
> >
> > +1
> >
> > > This patch updates these error messages to use schema-qualified names,
> > > improving the clarity of error reporting for CREATE PUBLICATION and
> > > ALTER PUBLICATION commands.
> > >
> > > This has been discussed on another thread [1]
> > >
> >
> > The patch works well.
> >
> > I think we can pull out
> > 'get_namespace_name_or_temp(RelationGetNamespace(targetrel))' and
> > 'RelationGetRelationName(targetrel)' into local variables to reduce
> > repetition and make the error paths a bit cleaner.
> >
> > const char *nspname =
> > get_namespace_name_or_temp(RelationGetNamespace(targetrel));
> > const char *relname = RelationGetRelationName(targetrel);
> >
>
> How about having a dedicated function to return the fully qualified
> relation name you want, which can then substitute the single %s.
>
> e.g.
> errmsg(errormsg, get_qualified_relname(targetrel)), ...

Yeah that makes sense. I will change this.


--
Regards,
Dilip Kumar
Google



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Parallel Apply
Next
From: Matthias van de Meent
Date:
Subject: Re: Startup process deadlock: WaitForProcSignalBarriers vs aux process