Re: Include schema-qualified names in publication error messages.

On Tue, May 5, 2026 at 10:27 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, May 4, 2026 at 10:51 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Thu, Apr 30, 2026 at 7:23 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > >
> > > On Thu, 30 Apr 2026 at 7:14 PM, Euler Taveira <euler(at)eulerto(dot)com> wrote:
> > >>
> > >>
> > >>
> > >> On Thu, Apr 30, 2026, at 4:37 AM, Dilip Kumar wrote:
> > >> >
> > >> > Yeah we may, but I feel what we have now looks more readable.
> > >> >
> > >>
> > >> My suggestion is that this function should be available in a central place.
> > >> That's not the only place that could use qualified schema and relation. If you
> > >> search for get_namespace_name_or_temp you will notice that this code path is
> > >> repeated in other parts of the code too (see ruleutils.c). It would be good if
> > >> we can have a common path for it. Maybe the signature has to be
> > >> get_qualified_relname(Oid) to accommodate
> > >
> > >
> > > IMHO it’s not a good idea to use Oid when you already have reldesc.
> >
> > +1.
> >
> > I looked at other use cases of get_namespace_name_or_temp(), and there
> > doesn’t seem to be any case where we already have a Relation
> > descriptor. So this appears to be a unique scenario, and I feel adding
> > a new function here makes sense. If needed, ruleutils.c’s
> > generate_qualified_relation_name() could be moved to a common location
> > in a separate patch.
> >
>
> I think for HEAD, we can move the common part of
> generate_qualified_relation_name() and get_qualified_relname() to a
> common function that takes relname as input. We can probably move it
> to lsyscache.c.

Done that, I think we need to pass nspid and relname.

> 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?

--
Regards,
Dilip Kumar
Google