Forums PostgreSQL.fr

flo

Membre

Locale et tri

J'ai une base PostgreSQL 8.3, sous Linux (RHEL 5).
On me demande de faire un tri insensible à la casse. Mais le cluster a été créé avec une locale C.

 =# SHOW LC_COLLATE;
  lc_collate
 ------------
  C
 (1 ligne)


 =# SHOW LC_CTYPE;
  lc_ctype
 ----------
  C
 (1 ligne)

Donc si je trie une table de cette manière, les accents sont placés à la fin :

select col1, col2 from testtri order by upper(col2)
;

  col2
--------
 ARBR
 ARBRE
 arbre
 ARBRI
 Epi
 Zinzin
 È
 É
 Épi
 Ê
 è
 é
 épi
 ê
(14 lignes)

Hors les utilisateurs veulent un ordre de tri français (donc "é" avant "Zinzin").
D'après la doc (http://docs.postgresqlfr.org/8.3/charset.html) on ne peut pas modifier les ordres de tri une fois le cluster créé.
Y a-t-il tout de même une solution autre que recréér le cluster (c'est pour une application déjà en production)
?
Merci.

Dernière modification par flo (23/11/2010 17:34:13)

Marc Cousin

Membre

Re : Locale et tri

Non, il n'y a pas. L'ordre de tri des chaînes est déterminé par le LC_COLLATE de la base. Si tu es coincée à C, il va falloir trier côté client je pense

C'est ce LC_COLLATE qui détermine le comportement de la fonction < entre deux chaînes.

Dernière modification par Marc Cousin (23/11/2010 17:37:56)

---

Marc.

gleu

Administrateur

Re : Locale et tri

Remarque que, si tu étais en 8.4, tu pourrais. Je dis juste ça comme ça

---

Guillaume.

Marc Cousin

Membre

Re : Locale et tri

Non, en 8.4, faudrait quand même créer une nouvelle base… et migrer les données dedans. À peine moins long que de créer un nouveau cluster.

Au passage, avoir le LOCALE à C, ça veut dire que les contraintes sur les varchar ne sont pas bonnes…

---

Marc.

flo

Membre

Re : Locale et tri

J'ai dit ça au client (de passer en 8.4),  mais ça ne l'a pas fait rire
Moi ça ne me fait pas rire non plus au passage (ce n'est vraiment pas facile à faire en php, au point que j'ai trouvé le conseil de le faire faire... par la base de données...). Et même avec une solution, c'est sans compter la masse de travail (quasiment tous les tableaux à refaire).
On est obligés de rester en 8.3.

Bon, tant pis. Merci pour la confirmation (je me doutais de la réponse )

jhashe

Membre

Re : Locale et tri

Bonjour,

Ayant été dans ce cas avant de tout migrer en PostgreSQL 9 (franchement, ça vaut le coup de réfléchir à une migration, et d'en profiter pour "basculer" en UTF8), j'avais adopté la stratégie suivante:

Création d'une fonction

CREATE OR REPLACE FUNCTION majuscule(character varying)
  RETURNS character varying AS
$BODY$SELECT UPPER(TRANSLATE($1,'ÉÈÊËéèêëàâùüçôîï','eeeeeeeeaauucoii')) AS RESULT$BODY$
  LANGUAGE sql IMMUTABLE;

Et la requête devient alors

select col1, col2 from testtri order by majuscule(col2);

gleu

Administrateur

Re : Locale et tri

Ça permet le tri mais le gros problème, c'est côté performance. Impossible d'utiliser un index sur col2 pour trier rapidement dans ce cas.

---

Guillaume.

jhashe

Membre

Re : Locale et tri

Je suis bien d'accord, c'est un pis-aller.
Mais, à l'époque où j'avais également des problèmes liés aux tris, ça m'a bien dépanné.

Et puis, je me trompe peut-être mais, dans des cas réels, souvent, on cherche à remonter un nombre d'enregistrement "raisonnable" et, dans ce cas, je suppose que le WHERE reste plus déterminant que le ORDER BY et peut dans ce cas continuer à exploiter les index.

gleu

Administrateur

Re : Locale et tri

Yep, c'est un pis-aller mais au moins ça fonctionne

---

Guillaume.

flo

Membre

Re : Locale et tri

Nous avons choisi ce style de solution également, au final (sauf qu'on n'a pas le droit non plus de faire du PL, donc on modifie toutes les requêtes pour ajouter le translate.