Skip site navigation (1) Skip section navigation (2)

Re: invalid multibyte character for locale

From: Stephane Bunel <stephane(at)stratum-ip(dot)net>
To: Daniel Verite <daniel(at)manitou-mail(dot)org>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: invalid multibyte character for locale
Date: 2005-03-05 01:36:06
Message-ID: 42290D06.5020206@stratum-ip.net (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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.

In response to

Responses

pgsql-fr-generale by date

Next:From: Daniel VeriteDate: 2005-03-05 10:04:55
Subject: Re: invalid multibyte character for locale
Previous:From: Daniel VeriteDate: 2005-03-04 14:47:39
Subject: Re: invalid multibyte character for locale

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group