Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions

On Tue, Nov 18, 2025 at 1:07 PM Fujii Masao <masao.fujii@gmail.com> wrote:

> On Tue, Nov 18, 2025 at 5:34 AM Masahiko Sawada <sawada.mshk@gmail.com>
> wrote:
> >
> > On Mon, Nov 17, 2025 at 8:44 AM Nathan Bossart <nathandbossart@gmail.com>
> 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/b1f9f399-3a1a-b554-283f-4ae7f34608e2@enterprisedb.com
>
> --
> 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,