BUG #6457: Regexp not processing word (with special characters on ends) correctly (UTF-8)
The following bug has been logged on the website:
Bug reference: 6457
Logged by: Albert Cieszkowski
Email address: albert.cieszkowski@cc.com.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.cieszkowski@cc.com.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.1329233225@sss.pgh.pa.us" type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:albert.cieszkowski@cc.com.pl">albert.cieszkowski@cc.com.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>
albert.cieszkowski@cc.com.pl writes:
peimp=> select 'Świnoujście' ~* '\mŚwinoujście\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