| From: | solai v <solai(dot)cdac(at)gmail(dot)com> |
|---|---|
| To: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
| Cc: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Kirill Reshke <reshkekirill(at)gmail(dot)com> |
| Subject: | Re: Use correct collation in pg_trgm |
| Date: | 2026-09-18 12:09:38 |
| Message-ID: | CAF0whud3tmkhcKotRtKW=EkaVQSsZKEQ-Frn+82qWd7gQUG8vw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi all,
On Fri, Sep 18, 2026 at 12:53 PM David Geier <geidav(dot)pg(at)gmail(dot)com> wrote:
>
> > Attached is v6 of the patch which fixes a problem with the tests:
> >
> > pg_trgm_collation_1.out mistakenly contained \endif at the end of the file.
> Attached is v7 of the patch set.
>
> No changes, except for rebasing on latest master and changing the "len"
> argument to "mblen" in
>
> extern int t_is##character_class##_with_len_collation(const char
> *ptr, int mblen, Oid collation); \
>
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.
Regards
Solai
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2026-09-18 12:28:55 | Re: Race conditions in logical decoding |
| Previous Message | Andrey Borodin | 2026-09-18 12:05:50 | Re: Reduce WAL volume for heap tuple hint bits |