On 22/08/2026 09:04, Rithvika Devisetti wrote:
On Thu, 2026-08-20 at 13:32 -0700, Jeff Davis wrote:
> Attached two patches. The first one is the same and backpatches through
> 18. The second defines some new macros and uses those, which is a
> better place to document the limits, and I'll only commit that one to
> master.
I applied both v2 patches and tested them on macOS 15 (aarch64,
clang 21), built with meson and --enable-cassert. Reporting results in
case an independent check on a non-Linux platform is useful.
Full test suite passes: 360 tests OK, 0 failures. The 40 skips are all
PG_TEST_EXTRA opt-ins (ssl, ldap, oauth, load_balance,
libpq_encryption, xid_wraparound). I ran saslprep separately with
PG_TEST_EXTRA=saslprep and it passes as well.
To exercise the changed path specifically, I used a database with
LOCALE_PROVIDER builtin / BUILTIN_LOCALE 'PG_UNICODE_FAST' and checked
the expanding case mappings:
upper('ß') -> 'SS' (2 codepoints)
upper('ffl') -> 'FFL' (3 codepoints)
upper('ΐ') -> 3 codepoints
upper('ῷ') -> 3 codepoints
casefold('ß') -> 'ss'
and drove ltree_crc32_sz() via ltree tables with GiST and btree indexes
over 1000 rows. No assertion failures from the new
Assert(foldlen < sizeof(foldstr)).
Hmm, so the code has this:
/*
* Expansion factor of string length, not including terminating NUL. That is,
* the upper bound of the number of multibyte characters in the result string
* per multibyte character in the input string.
*
* NB: assumes no provider exceeds the Unicode-defined maximum.
*/
#define PG_MAX_CASEMAP_MBCHARS UNICODE_MAX_CASEMAP_CODEPOINTS
Is it a number of codepoints or bytes? The comment says "multibyte
characters" which I think means codepoints in unicode, but the ltree
code does this:
/* max space required to map single codepoint, including NUL */
char foldstr[PG_CASEMAP_BUFSZ];
Which sure looks like # of bytes.
- Heikki
