Re: Wrong results using initcap() with non normalized string

2019-10-03 Thread Juan José Santamaría Flecha
On Sun, Sep 29, 2019 at 3:38 AM Alvaro Herrera  wrote:
>
> The UTF8 bits looks reasonable to me.  I guess the other part of that
> question is whether we support any other multibyte encoding that
> supports combining characters.  Maybe for cases other than UTF8 we can
> test for 0-width chars (using pg_encoding_dsplen() perhaps?) and drive
> the upper/lower decision off that?  (For the UTF8 case, I don't know if
> Juanjo's proposal is better than pg_encoding_dsplen.  Both seem to boil
> down to a bsearch, though unicode_norm.c's table seems much larger than
> wchar.c's).
>

Using pg_encoding_dsplen() looks like the way to go. The normalizarion
logic included in ucs_wcwidth() already does what is need to avoid the
issue, so there is no need to use unicode_norm_table.h. UTF8 is the
only multibyte encoding that can return a 0-width dsplen, so this
approach would also works for all the other encodings that do not use
combining characters.

Please find attached a patch with this approach.

Regards,

Juan José Santamaría Flecha
diff --git a/src/backend/utils/adt/formatting.c b/src/backend/utils/adt/formatting.c
index f7175df..8af62d2 100644
--- a/src/backend/utils/adt/formatting.c
+++ b/src/backend/utils/adt/formatting.c
@@ -1947,7 +1947,10 @@ str_initcap(const char *buff, size_t nbytes, Oid collid)
 wchar_t*workspace;
 size_t		curr_char;
 size_t		result_size;
+int			encoding;
+char		wdsplen[MAX_MULTIBYTE_CHAR_LEN];
 
+encoding = GetDatabaseEncoding();
 /* Overflow paranoia */
 if ((nbytes + 1) > (INT_MAX / sizeof(wchar_t)))
 	ereport(ERROR,
@@ -1968,7 +1971,9 @@ str_initcap(const char *buff, size_t nbytes, Oid collid)
 			workspace[curr_char] = towlower_l(workspace[curr_char], mylocale->info.lt);
 		else
 			workspace[curr_char] = towupper_l(workspace[curr_char], mylocale->info.lt);
-		wasalnum = iswalnum_l(workspace[curr_char], mylocale->info.lt);
+		wchar2char(wdsplen, [curr_char], MAX_MULTIBYTE_CHAR_LEN, mylocale);
+		if (pg_encoding_dsplen(encoding, wdsplen) != 0)
+			wasalnum = iswalnum_l(workspace[curr_char], mylocale->info.lt);
 	}
 	else
 #endif
@@ -1977,7 +1982,9 @@ str_initcap(const char *buff, size_t nbytes, Oid collid)
 			workspace[curr_char] = towlower(workspace[curr_char]);
 		else
 			workspace[curr_char] = towupper(workspace[curr_char]);
-		wasalnum = iswalnum(workspace[curr_char]);
+		wchar2char(wdsplen, [curr_char], MAX_MULTIBYTE_CHAR_LEN, mylocale);
+		if (pg_encoding_dsplen(encoding, wdsplen) != 0)
+			wasalnum = iswalnum(workspace[curr_char]);
 	}
 }
 


Re: Wrong results using initcap() with non normalized string

2019-09-28 Thread Alvaro Herrera
On 2019-Sep-22, Juan José Santamaría Flecha wrote:

> The attached patch addresses the comment about assuming UTF8.

The UTF8 bits looks reasonable to me.  I guess the other part of that
question is whether we support any other multibyte encoding that
supports combining characters.  Maybe for cases other than UTF8 we can
test for 0-width chars (using pg_encoding_dsplen() perhaps?) and drive
the upper/lower decision off that?  (For the UTF8 case, I don't know if
Juanjo's proposal is better than pg_encoding_dsplen.  Both seem to boil
down to a bsearch, though unicode_norm.c's table seems much larger than
wchar.c's).

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




Re: Wrong results using initcap() with non normalized string

2019-09-20 Thread Alvaro Herrera
On 2019-Sep-20, Tom Lane wrote:

> =?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?= 
>  writes:
> > I have come around a strange situation when using a unicode string
> > that has non normalized characters. The attached script 'initcap.sql'
> > can reproduce the problem.

For illustration purposes:

SELECT initcap('ŞUB');
 initcap 
─
 Şub
(1 fila)

SELECT initcap('ŞUB');
 initcap 
─
 ŞUb
(1 fila)

> If we're going to start worrying about non-normalized characters,
> I suspect there are far more places than this one that we'd have
> to consider buggy :-(.

I would think that we have to start somewhere, rather than take the
position that we can never do anything about it.

(ref: 
https://www.postgresql.org/message-id/flat/53E179E1.3060404%402ndquadrant.com )

-- 
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services




Re: Wrong results using initcap() with non normalized string

2019-09-20 Thread Tom Lane
=?UTF-8?Q?Juan_Jos=C3=A9_Santamar=C3=ADa_Flecha?=  
writes:
> I have come around a strange situation when using a unicode string
> that has non normalized characters. The attached script 'initcap.sql'
> can reproduce the problem.
> The attached patch can fix the issue.

If we're going to start worrying about non-normalized characters,
I suspect there are far more places than this one that we'd have
to consider buggy :-(.

As for the details of the patch, it seems overly certain that
it's working with UTF8 data.

regards, tom lane