Re: tsearch with Turkish locale ( was Re: foreign_data test fails with non-C locale)

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
Cc: Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>, pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: tsearch with Turkish locale ( was Re: foreign_data test fails with non-C locale)
Date: 2009-01-20 07:25:44
Message-ID: 49757C78.3090909@gmx.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Teodor Sigaev wrote:
>> ========================
>> 5 of 120 tests failed. ========================
>>
>> This is on a Fedora-9 x86 box, and:
>>
>> -bash-3.2$ rpm -qv glibc
>> glibc-2.8-8.i686
>
> Interesting. On my notebook all is ok.
> % uname -a
> FreeBSD ... 7.1-RELEASE-p2 FreeBSD 7.1-RELEASE-p2
>
> Is any possibility of broken locale?

Assuming that the locales on FreeBSD are the same or closely related to
the ones on Mac OS X, I would rather say that the BSD locales are
broken, because they don't actually support the Turkish case conversion
rules:

regression=# show lc_ctype;
lc_ctype
-------------
tr_TR.utf-8
(1 row)

regression=# select lower('SKIES');
lower
-------
skies
(1 row)

regression=# select upper('skies');
upper
-------
SKIES
(1 row)

Thus, the problem that the glibc locales appear to expose is masked here.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-01-20 09:03:16 Re: Visibility map and freezing
Previous Message Koichi Suzuki 2009-01-20 06:21:42 Re: V4 of PITR performance improvement for 8.4