Re: Stop asserting that Unicode normalization consumes its whole input

From: John Naylor <johncnaylorls(at)gmail(dot)com>
To: Tristan Partin <tristan(at)partin(dot)io>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Stop asserting that Unicode normalization consumes its whole input
Date: 2026-09-22 04:45:47
Message-ID: CANWCAZZYbQw4MwA7_E-0RXwv8oCvbpy+P2AEur5OieT-3_=8Fw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Sep 19, 2026 at 12:00 AM Tristan Partin <tristan(at)partin(dot)io> wrote:
>
> normalize() and IS NORMALIZED determine how many code points their input
> holds with pg_mbstrlen_with_len(). They then decode exactly that many
> code points, and assert afterward that this consumed the entire datum.
> That invariant does not hold because pg_mbstrlen_with_len() stops at the
> first of "limit" or a NUL.

The limit here is VARSIZE_ANY_EXHDR(input) , which is the entire
length. This patch seems like it's weakening an assertion for a case
that shouldn't happen. (I haven't looked at the tests in encoding.sql
that force non-standard behavior, so I'm not sure what the context was
there...)

--
John Naylor
Amazon Web Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2026-09-22 04:53:31 Re: Move system identifier generation to a common helper
Previous Message John Naylor 2026-09-22 04:34:21 Re: [PATCH] Refactor *_abbrev_convert() functions