Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Sugamoto Shinya <shinya34892@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Chao Li <li.evan.chao@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-18T15:31:35Z
Lists: pgsql-hackers
On Wed, Nov 19, 2025 at 12:20:34AM +0900, Sugamoto Shinya wrote: > On Tue, Nov 18, 2025 at 1:07 PM Fujii Masao <masao.fujii@gmail.com> wrote: >> 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? I think it makes sense to reserve it for cases with several 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. WFM -- nathan
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add HINT listing valid encodings to encode() and decode() errors.
- 99780da72096 19 (unreleased) landed
-
Revise GUC names quoting in messages again
- 17974ec25946 17.0 cited
-
doc: Mention how to use quotes with GUC names in error messages
- a243569bf65c 17.0 cited
-
Adjust assorted hint messages that list all valid options.
- 5ac51c8c9e44 16.0 cited