MIME-Version: 1.0
References: <aaEJ-El2seZHeFcG@paquier.xyz>
In-Reply-To: <aaEJ-El2seZHeFcG@paquier.xyz>
From: John Naylor <johncnaylorls@gmail.com>
Date: Wed, 18 Mar 2026 18:34:03 +0700
Message-ID: 
 <CANWCAZbgyvx66qfngNvW0n+uEv3=Bak1X5GLPr4sZApuHDPV-g@mail.gmail.com>
Subject: Re: Non-compliant SASLprep implementation for ASCII characters
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CANWCAZbgyvx66qfngNvW0n%2BuEv3%3DBak1X5GLPr4sZApuHDPV-g%40mail.gmail.com>
Precedence: bulk

On Fri, Feb 27, 2026 at 10:05=E2=80=AFAM Michael Paquier <michael@paquier.x=
yz> wrote:
>
> Even if we don't do 0002, 0001 shows benefits of its own.

Seems sensible to me. I only have minor nitpicks:

+operation for a single byte as well as a range of these, acting as thin
+wrappers standing on top of pg_saslprep().

It's more natural to say "wrappers around", at least that's what comes to m=
e.

+ if (unlikely(utf8_len =3D=3D 0))

The exceptional path only has two lines of code, so it's unclear what
this hint is trying to do. This module isn't run by default anyway

+ MemSet(nulls, false, sizeof(nulls));

Regular "memset" with a 4-byte constant input is easily inline-able by
the compiler, and I think we should use our homegrown implementation
only when there is a specific reason for it. (I know there are many
dozens of uses without a reason already, but...)

-is($result, 'U+0000|SUCCESS|\x00|\x', "Only nul authorized for all
valid UTF8 codepoints");
+is($result, '', "No empty or NULL values for all valid UTF8 codepoints");

I don't quite understand "only nul authorized..." -- I understand the
explanation in your email, but I having difficulty with the way it's
phrased here. (Although it'll be moot if we go ahead with 0002)

--=20
John Naylor
Amazon Web Services