Re: Open issues for collations - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Open issues for collations
Date
Msg-id 2466.1301356960@sss.pgh.pa.us
Whole thread Raw
In response to Re: Open issues for collations  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Open issues for collations
Re: Open issues for collations
Re: Open issues for collations
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> On lör, 2011-03-26 at 00:36 -0400, Tom Lane wrote:
>> * It'd sure be nice if we had some nontrivial test cases that work in
>> encodings besides UTF8.  I'm still bothered that the committed patch
>> failed to cover single-byte-encoding cases in upper/lower/initcap.

> Well, how do we want to maintain these test cases without doing too much
> duplication?  It would be easy to run a small sed script over
> collate.linux.utf8.sql to create, say, a latin1 version out of it.

I tried.  The upper/lower test cases require Turkish characters that
aren't in Latin1.  I'm not sure if we can readily produce test cases
that cover both sorting changes and case-folding changes in just one
single-byte encoding --- anybody?

One thing I noticed but didn't push to committing is that the test case
has a largely-unnecessary assumption about how the local system's locale
names spell "utf8".  We could eliminate that by having it use the
trimmed locale names created by initdb.  I would've made more of a push
for that if it resulted in a test case that passed on OS X, but it turns
out that once you get past the locale name spelling, you find out that
Macs still can't sort UTF8 strings correctly :-(
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Libpq PGRES_COPY_BOTH - version compatibility
Next
From: Alvaro Herrera
Date:
Subject: Re: Open issues for collations