Message-ID: <40afd8a3-d22e-437f-8eec-94462a6960d2@gmail.com>
Date: Fri, 18 Sep 2026 17:09:11 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Use correct collation in pg_trgm
To: solai v <solai.cdac@gmail.com>
Cc: Zsolt Parragi <zsolt.parragi@percona.com>,
 Alexander Korotkov <aekorotkov@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
 Heikki Linnakangas <hlinnaka@iki.fi>, Kirill Reshke <reshkekirill@gmail.com>
References: <db087c3e-230e-4119-8a03-8b5d74956bc2@gmail.com>
 <CAN4CZFN83RsDejW5e9P1pCzAB6LKCgsBkAZk-4Y_UscBXtdJ1Q@mail.gmail.com>
 <1981b5f0-7d06-4911-a231-23bbb6bf504c@gmail.com>
 <CAN4CZFP5oVKkjAeb7-jrWR8spqvnhQq7HSTMhpWBiYuPmtqyjg@mail.gmail.com>
 <CAPpHfdvWbF2S6fsc+dF=7OjLG6iFXVcDH+MK0aVKzaH9iptLvQ@mail.gmail.com>
 <6f983adb-fd5d-4e0e-8400-513fbea304e0@gmail.com>
 <CAN4CZFNSfFYtGZSE0ow-YCwZAZWqqfDOxLkJa8UdrOkX9P0u2Q@mail.gmail.com>
 <7ae842f2-779c-466e-841d-d11e419a9428@gmail.com>
 <27121a4c-2186-47ad-84c4-136b99413df1@gmail.com>
 <8e054492-3984-403e-a959-9b2a6a85f3eb@gmail.com>
 <f4db25c8-97e4-4d14-a316-eeed538b6579@googlemail.com>
 <CAF0whud3tmkhcKotRtKW=EkaVQSsZKEQ-Frn+82qWd7gQUG8vw@mail.gmail.com>
Content-Language: en-US
From: David Geier <geidav.pg@gmail.com>
In-Reply-To: 
 <CAF0whud3tmkhcKotRtKW=EkaVQSsZKEQ-Frn+82qWd7gQUG8vw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/40afd8a3-d22e-437f-8eec-94462a6960d2%40gmail.com>
Precedence: bulk

Hi Solai!

> I reviewed the v7 patch series and I tested the changes with a Turkish
> ICU collation and verified that the collation is now correctly
> propagated for both trigram lowercasing and word-boundary detection.
> For the lowercasing changes, show_trgm('ISTANBUL' COLLATE "tr-x-icu")
> now produces the same trigrams as show_trgm('ıstanbul' COLLATE
> turkish), and:
> 
> similarity('ıstanbul' COLLATE turkish,
>            'ISTANBUL' COLLATE turkish)
> 
> returns 1, whereas the unpatched behavior produced 0.5.
> 
> I also tested the word-boundary handling using: helloıtestIworldİcode,
> with both Turkish ICU and "C" collations. The generated trigrams
> differ appropriately between the two collations, confirming that the
> collation is being used while identifying word boundaries. I tested
> the index paths as well. A GIN trigram index and a GiST trigram index
> both work correctly for a query using the matching Turkish collation.
> And also tested an explicitly "C"-collated LIKE query against the
> Turkish-collated column with sequential scans disabled. The planner
> did not use the Turkish trigram index and instead showed a disabled
> sequential scan, which avoids using an index with an incompatible
> collation. Finally, I ran the complete pg_trgm installcheck suite and
> all 5 tests passed successfully. I then ran: git diff HEAD~2..HEAD
> --check, which reported one minor formatting issue:
> contrib/pg_trgm/sql/pg_trgm_collation.sql:29: new blank line at EOF.
> This appears to be only a patch formatting issue. I have not modified
> the contributor's patch for this; I am mentioning it here as a minor
> review comment.
> Other than the above minor formatting point, I did not find any
> functional issues during my testing.

Thanks for the thorough review.

I think with that it's ready for committer.
Marked accordingly in the commitfest app.

--
David Geier