Re: Fix for fragile code in ltree/crc32.c

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)).

Regards,
Rithvika Devisetti

On Thu, Aug 20, 2026 at 1:32 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:

> On Wed, 2026-08-19 at 10:44 +0300, Heikki Linnakangas wrote:
> > Looking at pg_strfold() (and other similar functions), there's no
> > indication that there's an upper bound on the destination size like
> > this. Does UNICODE_CASEMAP_BUFSZ work for all collation providers and
> > locales? How about adding a comment in pg_strfold() and friends about
> > that?
>
> 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.
>
> Along with the Case Mapping Complexities comment I'm adding here:
>
>
> https://www.postgresql.org/message-id/fe35594a54923c94142390dabb365b737c581f2a.camel@j-davis.com
>
> (which will be backpatched to 18), I think that should be sufficient,
> but I could add another note there about the byte limits if you think
> it would be worthwhile.
>
> Regards,
> Jeff Davis
>
>