| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Yet another bug in nondeterministic LIKE |
| Date: | 2026-07-04 17:59:46 |
| Message-ID: | 391592.1783187986@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
While studying the reported bug #19474 [1], I realized that there's
still another bug with nondeterministic LIKE's handling of escape
characters. If there's an escape at the start of the pattern
(or just after a wildcard), and it's escaping an ordinary character,
we handle that with code that only works for deterministic collations.
This at least gives wrong answers:
u8=# select 'AB' like 'a\b' collate case_insensitive; -- okay
?column?
----------
t
(1 row)
u8=# select 'AB' like '\ab' collate case_insensitive; -- not okay
?column?
----------
f
(1 row)
and it can also result in invoking pg_strncoll() on a partial
multibyte character. I didn't try to build a test case showing
misbehavior from that, but there probably is some.
The fix is pretty simple, just re-order the stanzas in MatchText's
loop. I couldn't resist the temptation to do some additional
janitorial work though.
regards, tom lane
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-mishandling-of-leading-in-nondeterministic-LI.patch | text/x-diff | 9.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrey Borodin | 2026-07-04 18:41:07 | Re: Missing FSM Update when Updating VM On-access |
| Previous Message | Kirill Reshke | 2026-07-04 17:38:54 | GIN index fast list search may become un-interruptible for long time. |