Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
BUG #6457: Regexp not processing word (with special characters onends) correctly (UTF-8)
The following bug has been logged on the website: Bug reference: 6457 Logged by: Albert Cieszkowski Email address: albert(dot)cieszkowski(at)cc(dot)com(dot)pl PostgreSQL version: 9.0.6 Operating system: CentOS 5.x Description: OS, base and client encoding UTF-8: peimp=> select 'Świnoujście' ~* '\mŚwinoujście\M'; ?column? ---------- f (1 row) peimp=> select 'Świnoujście' ~* '\AŚwinoujście\Z'; ?column? ---------- t (1 row) but: peimp=> select 'Mróz' ~* '\mmróZ\M'; ?column? ---------- t (1 row) peimp=> select 'Mróz' ~* '\AmróZ\Z'; ?column? ---------- t (1 row) I believe it is connected with bug #5766 and #3433.
albert(dot)cieszkowski(at)cc(dot)com(dot)pl writes: > OS, base and client encoding UTF-8: What's your lc_collate/lc_ctype settings? regards, tom lane
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello Tom,<br>
<br>
Every lc_x value is pl_PL.UTF8 (corresponding to the word's
language).<br>
Database was created with --locale=pl_PL.UTF8.<br>
OS (CentOS 5.x) uses: en_US.UTF-8<br>
<br>
Best regards,<br>
Albert Cieszkowski<br>
<br>
W dniu 2012-02-14 16:27, Tom Lane pisze:
<blockquote class=" cite" id="mid_7784_1329233225_sss_pgh_pa_us"
cite="mid:7784(dot)1329233225(at)sss(dot)pgh(dot)pa(dot)us" type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:albert(dot)cieszkowski(at)cc(dot)com(dot)pl">albert(dot)cieszkowski(at)cc(dot)com(dot)pl</a> writes:
</pre>
<blockquote class=" cite" id="Cite_0" type="cite">
<pre wrap="">OS, base and client encoding UTF-8:
</pre>
</blockquote>
<pre wrap="">What's your lc_collate/lc_ctype settings?
regards, tom lane
</pre>
</blockquote>
</body>
</html>
Attachment: unknown_filename
Description: text/html (1005 bytes)
Description: text/html (1005 bytes)
albert(dot)cieszkowski(at)cc(dot)com(dot)pl writes: > peimp=> select 'winoujcie' ~* '\mwinoujcie\M'; > ?column? > ---------- > f > (1 row) Oh, I see the reason for this: the code in cclass() in regc_locale.c doesn't go further up than U+00FF, so no codes above that will be thought to be letters (or members of any other character class). Clearly we need to go further when we are dealing with UTF8. I'm not sure what a sane limit would be though. (It would be nice if there were a more efficient way to get this information than laboriously iterating through all the possible character codes. It doesn't look like we're even trying to cache the results, ick.) regards, tom lane
On 14 Feb 2012, at 18:28, Tom Lane wrote: > > Oh, I see the reason for this: the code in cclass() in regc_locale.c > doesn't go further up than U+00FF, so no codes above that will be > thought to be letters (or members of any other character class). > Clearly we need to go further when we are dealing with UTF8. > I'm not sure what a sane limit would be though. The Basic Multilingual Plane goes up to FFFF: https://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Planes
On 14 Feb 2012, at 18:28, Tom Lane wrote: > > Oh, I see the reason for this: the code in cclass() in regc_locale.c > doesn't go further up than U+00FF, so no codes above that will be > thought to be letters (or members of any other character class). > Clearly we need to go further when we are dealing with UTF8. > I'm not sure what a sane limit would be though. The Basic Multilingual Plane goes up to FFFF: https://en.wikipedia.org/wiki/Mapping_of_Unicode_characters#Planes