| From: | Nitin Motiani <nitinmotiani(at)google(dot)com> |
|---|---|
| To: | Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Fix for bug #19474: LIKE fails to match literal backslashes with nondeterministic collations |
| Date: | 2026-05-15 11:53:31 |
| Message-ID: | CAH5HC96PzfLzNAemhxPMdKRO7U+ubXCkq5zhYxNzm_YoP+VpgQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thanks Zsolt for the review.
>
> The code isn't easy to reason about like this, it relies on specific
> details of the outer loop, which was only mentioned in the email
> itself.
>
> This should be also explained in a comment and the commit message, or
> maybe instead of the current way, the loop could work similarly like
> how another loop uses an afterescape flag in do_like_escape (in the
> same file), that form seems less fragile.
>
I have changed the code to use an 'afterescape' flag like in
'do_like_escape'. I also realized that 'do_like_escape' uses NextChar
to handle multibyte encodings. So I changed the byte by byte copy to
use NextChar and then copy the whole character. I think byte-by-byte
copying should be enough for most cases, but if an encoding has '\' as
second or third byte, that might not work.
This copying can also be done with CopyAdvChar, as 'do_like_escape'
does, but that macro is not defined for all cases. So for the time
being, I just used NextChar and copied the character myself. We can
also define CopyAdvChar and ust it here for the code to be consistent
across functions.
Let me know your thoughts on the above approaches.
Regards,
Nitin Motiani
Google
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Fix-LIKE-matching-with-nondeterministic-collation.patch | application/x-patch | 4.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-05-15 11:56:46 | Re: COPY ON_CONFLICT TABLE; save duplicated record to another table. |
| Previous Message | Nikita Malakhov | 2026-05-15 11:53:14 | Re: SQL/JSON json_table plan clause |