Hello, At Tue, 25 Aug 2026 22:19:30 -0700, Bharath Rupireddy <[email protected]> wrote in > Hi, > > On Tue, Aug 25, 2026 at 9:53 PM Amit Kapila <[email protected]> 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
