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+8_5eoTx8ZrY+Z5iO669pzTVL3XE=9+wwQ1MjqejBwBOA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions
List pgsql-hackers
Thanks everyone for reviewing my proposal. Please let me know if you have something to discuss here.


2025年11月19日(水) 0:31 Nathan Bossart <nathandbossart@gmail.com>:
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

pgsql-hackers by date:

Previous
From: Akshay Joshi
Date:
Subject: Re: [PATCH] Add pg_get_database_ddl() function to reconstruct CREATE DATABASE statement
Next
From: jian he
Date:
Subject: Re: Doc: add XML ID attributes to tags for create_foreign_table, alter_foreign_table