Обсуждение: Problem with Upper/Lower Function

I fond a problem at the RC1 of PostgreSQL (W32 - Version)

When you use the UPPER or LOWER function with German letters (=E4,=F6,=FC) =
this
letters stay in lower/upper case.
You can reproduce this error with this simple examples:

select upper('=FC');
select upper('T=FCte');

Test
ID    |   sText=20=20=20
-------------------
1        |   T=DCTE
2    |   EIMER

select * from Test where sText =3D upper('t=FCte');


I can reproduce this problem in several computers.




Mit freundlichen Gruessen / with best regards

Hendrik Hesse
--------------------------------------------------
P O L Y S I U S   AG
Abt. 164=20
Graf-Galen-Str. 17
59269 Beckum
Tel.:    +49 (0)2525 99 2076
Fax.:    +49 (0)2525 99 2100
mailto:Hendrik.Hesse@thyssenkrupp.com
http://www.polysius.com

"Hesse, Hendrik" <hendrik.hesse@thyssenkrupp.com> writes:
> When you use the UPPER or LOWER function with German letters (ä,ö,ü) this
> letters stay in lower/upper case.

Sounds like you picked the wrong locale setting, or an invalid
combination of locale and encoding.

            regards, tom lane

Hello,

Hesse, Hendrik schrieb am 16.12.2004 16:41:
> I fond a problem at the RC1 of PostgreSQL (W32 - Version)
>
> When you use the UPPER or LOWER function with German letters (ä,ö,ü) this
> letters stay in lower/upper case.
> You can reproduce this error with this simple examples:
>
> select upper('ü');
> select upper('Tüte');
>
> Test
> ID    |   sText
> -------------------
> 1        |   TÜTE
> 2    |   EIMER
>
> select * from Test where sText = upper('tüte');
>
>
> I can reproduce this problem in several computers.

right now you can only use database encoding "LATIN1" (without
euro-sign) or "LATIN10" for german text. "UNICODE" doesn't work with
umlauts, sharp s or euro-sign.

Because of missing conversion functions to win1252 (Windows default
encoding on german MS systems) you must use same encoding on client side
        as for the database, or UNICODE on client side, if your
application supports it.

I prepared a patch for WIN1252 encoding on db and client side, which
will probably be included in version 8.1 (V8.0 is closed for new features).

An alternative is to use an encoding for the database, which you
normally don't use (e.g. WIN1250) in conjunction with a patched
conversion DLL (e.g. utf8_and_win1250.dll), so you can use either
WIN1250 (which represents WIN1252) or UNICODE on client side. This way I
do it until real WIN1252-support is available.


With best regards,

Roland.