Re: Assertion failure in GetSubscriptionRelations() with concurrent DROP TABLE

Hello,

At Tue, 25 Aug 2026 22:19:30 -0700, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> Hi,
>
> On Tue, Aug 25, 2026 at 9:53 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > That said, I agree that %d would be safer if we want to make the error
> > handling robust against an arbitrary/invalid byte say due to catalog
> > corruption. As Vignesh pointed out, though, %c is currently the common
> > convention for printing relkind, whereas %d is used only in one place.
> >
> > So perhaps we should keep %c in this patch and, if we want to adopt %d
> > for unexpected relkind values, let's handle the existing %c usages
> > consistently in a separate patch.
> >
> > Thoughts?
>
> I looked at the most common and widely used path, which is
> errdetail_relkind_not_supported(). It uses %c (some of these might be
> user-visible errors). I prefer to go with that, so +1 to use %c in
> this patch and discuss the use of %d separately if that's a concern.

If this case has been considered and the choice of %c is intentional,
I have no objection to it.

Regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center