Re: [PG19] ILIKE index scan misses rows with a libc UTF-8 collation on macOS

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: shihao zhong <zhong950419(at)gmail(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: [PG19] ILIKE index scan misses rows with a libc UTF-8 collation on macOS
Date: 2026-10-26 22:15:50
Message-ID: 3d7089f08ce522157bcc012f4a6c3ea59b91e35b.camel@j-davis.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 2026-10-19 at 22:20 -0400, shihao zhong wrote:
> I would keep it on all platforms. ILIKE compares with towlower() on
> every platform, so this check is what it needs everywhere. Where the
> C
> library is consistent it changes nothing. I went over every code
> point
> with glibc 2.39 and musl 1.2.5, and the new checks add no character
> there. It only runs at plan time. 

Committed. Thank you!

> > Then, I would suggest adding a regression test so that CI can help
> > check whether the problem exists on other platforms.
>
> Done in 0002.

I did not commit the test. I think we need to agree on a general way to
test libc better, rather than add a new test just for this. I don't
oppose a test here, though.

Regards,
Jeff Davis

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Bryan Green 2026-10-26 22:06:25 Don't close relation files when the visibility map is extended