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

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Sugamoto Shinya <shinya34892(at)gmail(dot)com>, 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 04:07:04
Message-ID: CAHGQGwEKaPa3B8mqU5VUbAAbr26LE7scbDV2LAAivLOz8w65KQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Nov 18, 2025 at 5:34 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Mon, Nov 17, 2025 at 8:44 AM Nathan Bossart <nathandbossart(at)gmail(dot)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(at)enterprisedb(dot)com

--
Fujii Masao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2025-11-18 04:39:50 Re: Extended Statistics set/restore/clear functions.
Previous Message Chao Li 2025-11-18 03:58:16 Re: vacuumdb: add --dry-run