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