Re: Non-compliant SASLprep implementation for ASCII characters - Mailing list pgsql-hackers

From John Naylor
Subject Re: Non-compliant SASLprep implementation for ASCII characters
Date
Msg-id CANWCAZbgyvx66qfngNvW0n+uEv3=Bak1X5GLPr4sZApuHDPV-g@mail.gmail.com
Whole thread
In response to Non-compliant SASLprep implementation for ASCII characters  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Non-compliant SASLprep implementation for ASCII characters
List pgsql-hackers
On Fri, Feb 27, 2026 at 10:05 AM Michael Paquier <michael@paquier.xyz> 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 me.

+ if (unlikely(utf8_len == 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)

--
John Naylor
Amazon Web Services



pgsql-hackers by date:

Previous
From: Junwang Zhao
Date:
Subject: Re: SQL Property Graph Queries (SQL/PGQ)
Next
From: Tatsuo Ishii
Date:
Subject: Re: Row pattern recognition