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

From vignesh C
Subject Re: Include schema-qualified names in publication error messages.
Date
Msg-id CALDaNm18+5U6m+w4ms4E7ndFxVF032d=c1dT3mRPtdUd55mScQ@mail.gmail.com
Whole thread
In response to Re: Include schema-qualified names in publication error messages.  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Include schema-qualified names in publication error messages.
Re: Include schema-qualified names in publication error messages.
List pgsql-hackers
On Wed, 6 May 2026 at 09:27, Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Tue, May 5, 2026 at 5:56 PM Euler Taveira <euler@eulerto.com> wrote:
> >
> > On Tue, May 5, 2026, at 7:42 AM, Amit Kapila wrote:
> > > On Tue, May 5, 2026 at 4:02 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > >>
> > >> > Now, we also need to decide whether to backpatch the relevant change
> > >> > to back-branches. It seems we didn't get the bug-report yet but
> > >> > clearly what we do currently is not correct. So, we should ideally
> > >> > backpatch it and in the back branches we don't need to expose it.
> > >> > OTOH, as it is reported and is not a big issue, so we can keep this as
> > >> > a HEAD only change as well. If we want to keep this as a HEAD only
> > >> > change then shall we wait for PG20 branch to open or go for current
> > >> > HEAD itself? What do you and or others think on this matter?
> > >>
> > >> I think we should apply in PG19. Although back-patching isn't
> > >> critical, since we already have an opportunity to fix it in PG19, why
> > >> not push it early?
> > >>
> > >
> > > I also think we should push it for PG19 especially because the EXCEPT
> > > feature increased the usage of relation names without schema-name in
> > > error messages. However, as we are past feature freeze, I wanted to
> > > know the opinion of others as well.
> > >
> >
> > -1 for backpatching.
> >
>
> Agreed.
>
> > These messages (without schema qualification) has been
> > like this since the beginning. The function was not introduced by fd366065e06a
> > and the proposed patch are changing existing messages as well. It is a good
> > idea to keep visible messages (WARNING, ERROR, FATAL, PANIC) consistent so as
> > not to break log analysis tools.
> >
> > I would say the target is v20. However, as Amit said, the change to the EXCEPT
> > clause message might be important, so I suggest changing it; I would leave the
> > other messages for the RMT to decide.
> >
>
> Okay, then we can split the patch into two, the first patch to make
> the required changes only for EXCEPT, and the second one for the
> remaining pre-existing messages. We can push the first patch in HEAD
> and wait for some more opinions on the second one.

The updated patch has the changes to split it.

Regards,
Vignesh

Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: FOR PORTION OF does not recompute GENERATED STORED columns that depend on the range column
Next
From: Amit Kapila
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication