From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Daniel Verite <daniel(at)manitou-mail(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Support LIKE with nondeterministic collations |
Date: | 2024-05-03 14:12:46 |
Message-ID: | 2ab6ec19-f9a9-4960-81f8-54028afb496e@eisentraut.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03.05.24 15:20, Robert Haas wrote:
> On Fri, May 3, 2024 at 4:52 AM Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>> What the implementation does is, it walks through the pattern. It sees
>> '_', so it steps over one character in the input string, which is '.'
>> here. Then we have 'foo.' left to match in the input string. Then it
>> takes from the pattern the next substring up to but not including either
>> a wildcard character or the end of the string, which is 'oo', and then
>> it checks if a prefix of the remaining input string can be found that is
>> "equal to" 'oo'. So here it would try in turn
>>
>> '' = 'oo' collate ign_punct ?
>> 'f' = 'oo' collate ign_punct ?
>> 'fo' = 'oo' collate ign_punct ?
>> 'foo' = 'oo' collate ign_punct ?
>> 'foo.' = 'oo' collate ign_punct ?
>>
>> and they all fail, so the match fails.
>
> Interesting. Does that imply that these matches are slower than normal ones?
Yes, certainly, and there is also no indexing support (other than for
exact matches).
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-05-03 14:13:43 | Re: pg_trgm comparison bug on cross-architecture replication due to different char implementation |
Previous Message | Peter Eisentraut | 2024-05-03 14:09:58 | Re: Document NULL |