Vous n'êtes pas identifié(e).
Bonjour,
J'utilise PostgreSQL 8.3.7 en français (UTF-8), et j'ai remarqué que l'opérateur ~* était sensible à la casse des caractères accentués, contrairement au comportement attendu (cf. § 9.7.3, page 117 du manuel en français). Par exemple :
CREATE TABLE "text_irex" (
"prénom" character varying(32) NOT NULL
);
INSERT INTO "test_irex" VALUES ('Édouard VII');
INSERT INTO "test_irex" VALUES ('Aliénor d’Aquitaine');
INSERT INTO "test_irex" VALUES ('Richard Cœur de Lion');
INSERT INTO "test_irex" VALUES ('Œdipe');
SELECT * FROM "test_irex" WHERE "prénom" ~* 'é';On ne retrouve qu'Aliénor d'Aquitaine.
SELECT * FROM "test_irex" WHERE "prénom" ILIKE '%é%';On retrouve Édouard VII et Aliénor.
SELECT * FROM "test_irex" WHERE "prénom" ~* 'A';On retrouve Édouard, Aliénor et Richard.
S'agit-il d'un problème connu ?
Hors ligne
Oui. D'après ce message (http://archives.postgresql.org/message- … .pgh.pa.us), Tom Lane reconnaît que la recherche par expression rationnelle est un brin mal foutue pour la recherche sur les variantes des caractères multi-octets. Autrement dit, pas de gestion des majuscules/minuscules pour ce qui sort des codes ASCII 7 bits. C'est sur la TODO list, si ce travail vous tente 
Bref, la seule variante possible est ILIKE.
Guillaume.
Hors ligne
Ça a malheureusement l'air vrai.
Ça fait partie des choses qui devaient être corrigées en 8.3 en théorie, mais peut être que ça n'a pas été corrigé pour ce cas particulier ?
Je crois que ça mérite un rapport de bug (je viens de le vérifier aussi en 8.4, en fr_FR.UTF-8). Et ça le fait en varchar comme en text.
Marc.
Hors ligne
Trop lent, et j'avais pas trouvé le message
Par contre, vu qu'il doit s'agir de fonctionnalité de recherche, habituellement, on supprime les accents avant de les faire. Ça doit être pour cela que personne ne s'est attelé au problème pour le moment.
Marc.
Hors ligne