Request a Demo
Home   >   mailing lists

Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions - Mailing list pgsql-hackers

From Sugamoto Shinya
Subject Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions
Date
Msg-id CAAe3y+_qYz0SfuG4uh+9KZ=f7LNp7wV1X7pXQNuxhuQ=s0E5ww@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions
List pgsql-hackers
Tree view
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,

pgsql-hackers by date:

Previous
From: 河田達也
Date:
Subject: Re: [PATCH] Add memory usage reporting to VACUUM VERBOSE
Next
From: Nathan Bossart
Date:
Subject: Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions