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

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Sugamoto Shinya <shinya34892(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions
Date: 2025-11-18 15:31:35
Message-ID: aRyRV4MWGTWcl8bz@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
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(dot)fujii(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Álvaro Herrera 2025-11-18 15:39:05 Re: pg_createsubscriber --dry-run logging concerns
Previous Message Sugamoto Shinya 2025-11-18 15:20:34 Re: [PATCH] Add hints for invalid binary encoding names in encode/decode functions