Re: invalid multibyte character for locale

Daniel Verite wrote:
> Stéphane Bunel wrote:
>
>
>>Dans le cas de upper()/lower()..., je penche pour un comportement
>>modifié dans le cas de chaîne multibyte. Là ou PG7.4 ne cherchait pas à
>>interpréter un caractère non "compris" comme pouvant être mis en
>>majuscule, cas pour upper(), tel qu'un 'é'. PG7.4 recopie tout
>>simplement le caractère. Alors que PG8 échoue s'il n'est pas capable de
>>trouver une conversion. Il serait plus strict que PG7.4 ou alors
>
>
> Oui il est plus strict, et c'est relatif au serveur lui-même.
> La solution est d'initialiser dès le départ le cluster avec une "locale"
> compatible avec l'utf-8.
>
> Par exemple
> initdb -E UNICODE --locale=fr_FR.utf8

Merci.
En effet ça fonctionne avec ceci :
initdb -E UNICODE --lc-ctype=en_US.utf8

>psql template1
Welcome to psql 8.0.1, the PostgreSQL interactive terminal.

Type: \copyright for distribution terms
\h for help with SQL commands
\? for help with psql commands
\g or terminate with semicolon to execute query
\q to quit

template1=# set client_encoding to 'latin9';
SET
template1=# select upper( 'Stéphane' );
upper
----------
STÉPHANE
(1 row)

Mais ce n'est pas sans contrainte. A ce que j'ai pu lire sur le sujet
avoir une locale utf8 (en fait différente de 'C' ou 'POSIX') coûte chère
en performance :

The drawback of using locales other than C or POSIX in PostgreSQL is its
performance impact. It slows character handling and prevents ordinary
indexes from being used by LIKE. For this reason use locales only if you
actually need them.

http://www.postgresql.org/docs/8.0/interactive/charset.html

Un autre problème : Si l'on possède une base avec un encoding différent
de celui utilisé à la création du cluster le comportement sera encore
différent. Pour tester j'ai crée un base test avec un encoding latin9.
Voici le résultat de la même requête que plus haut (client_enconding =
Latin9 également) :

test=# select upper( 'Stéphane' );
upper
----------
STéPHANE

Le 'é' na pas été convertis. En revanche on retrouve le comportement de
PG7.4

Moralité il demeure de grosses différences *fonctionnelles* entre PG7.4
et PG8 qui ne sont pas pour simplifier la vie du DBA devant gérer autre
chose que de l'ASCII dans ses bases.

Stéphane.