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

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Fix for fragile code in ltree/crc32.c
Date: 2026-08-20 20:32:39
Message-ID: 018e9fb8bf37351dcd8945a51949ccce6e73de44.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Attachment Content-Type Size
v2-0001-ltree-crc32.c-fix-fragile-code.patch text/x-patch 1.5 KB
v2-0002-pg_locale.h-define-casemapping-limits.patch text/x-patch 4.5 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2026-08-20 21:08:24 Re: Fix for fragile code in hashtext()
Previous Message Tom Lane 2026-08-20 20:06:39 Re: Allow a prosupport function to be attached to an aggregate