On Tue, Nov 18, 2025 at 1:07 PM Fujii Masao <[email protected]> wrote:
> On Tue, Nov 18, 2025 at 5:34 AM Masahiko Sawada <[email protected]> > wrote: > > > > On Mon, Nov 17, 2025 at 8:44 AM Nathan Bossart <[email protected]> > wrote: > > > > > > On Mon, Nov 17, 2025 at 04:04:17PM +0100, Daniel Gustafsson wrote: > > > > Oh right, I had forgotten about that, thanks for the reminder. The > patch as > > > > proposed is correct then. > > > > > > The patch is probably fine as-is, but this seems like a candidate for > the > > > ClosestMatch stuff added by commit 5ac51c8. > > > > +1 > > Is there a guideline on when we should use the ClosestMatch machinery > instead of explicitly listing valid values? From the discussion in [1], > it seems appropriate when there are many possible values. > But should we generally replace all hints that list valid values > with ClosestMatch, or only in specific cases? > > Regards, > > [1] > https://www.postgresql.org/message-id/flat/[email protected] > > -- > Fujii Masao > > Is there a guideline on when we should use the ClosestMatch machinery instead of explicitly listing valid values? As far as I checked the source code, I couldn't find any related documentation except the discussions. Maybe we should add some explanations about this to `doc/src/sgml/sources.sgml`, especially in the Error Message Style Guide section. > From the discussion in [1], it seems appropriate when there are many possible values Personally I agree with this. Since there are only the four options in this case, it wouldn't be difficult for users to find a correct encoding from the hint message even without showing a possible encoding. Also, using ClosestMatch here to show a possible encoding would encourage similar additions later which might bloat our error handling. Keeping code simple by notifying the user of the valid encodings should be sufficient for this part. Regards,
