Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Je souhaiterai pouvoir lancer des recherches plein texte insensibles aux accents (ce n'est pas le cas par défaut sous PostgreSQL).
Grâce à l'excellent blog de Guillaume Lelarge, j'ai une possible solution:
http://blog.guillaume.lelarge.info/inde … es-accents
Malheureusement, mon serveur est sous CentOS 5 (clône de RedHat 5) en x64, et la librairie utilisée (libunac1) semble ne pas avoir été portée sur cet OS. J'ai donc téléchargé les sources pour la compiler et... j'ai obtenu plusieurs erreurs (le code semble ancien et incompatible avec gcc4 utilisé sous RH5). J'ai modifié les sources jusqu'à ce que la librairie compile.
Je me suis ensuite attelé à la compilation du module lui-même... qui m'a posé les mêmes difficulés (messages d'erreurs à la compilation). Là encore, j'ai modifié les sources jusqu'à ce que ça compile.
J'allais crier victoire quand, dans PostgreSQL, j'ai pu créer les fonctions (via \i /opt/postgresql-8.3/share/contrib/unaccent.sql) sauf que... j'ai eu le droit à un joli segfault. J'ai même eu peur de ne pas réussir à relancer mon PostgreSQL qui me refaisait un segfault à chaque redémarrage :-(
Si une âme charitable connaissait un moyen d'obtenir ou de correctement compiler libunac et le module postgresql-unaccent, je lui serais TRES reconnaissant.
Par avance, merci pour votre aide,
Jérôme
Hors ligne
Bonjour,
Je te conseille de rapporter ces différents problèmes directement aux développeurs de PostgreSQL :
http://www.postgresql.org/support/submitbug
http://www.postgresql.org/docs/current/ … rting.html
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Merci pour ta réponse, mais cela me gêne un peu. En effet, le problème ne vient pas a priori de PostgreSQL lui-même, mais plutôt de la compilation des 2 librairies tierces. D'ailleurs, ça ne pose visiblement pas de problème sous Debian, qui propose déjà libunac1 dans ses dépôts.
Hors ligne
J'ai trouvé ça pour le support de libunac sous GCC4. En espérant que ça puisse servir.
La méthode doit être proche de ceci :
- Installer le rpm source : http://download.gna.org/unac/rpm/unac-1.7.0-1.src.rpm
- Patcher les deux fichiers installés avec les patchs de la page ci dessus (ils auront atterri dans /usr/src/redhat ou quelque chose du genre)
- Aller à l'endroit ou se trouve le .spec et compiler le rpm (rpmbuild -bb machin.spec)
- Installer les rpms qui en résultent
Marc.
Hors ligne
Merci beaucoup !
J'essayerai et, si ça marche, je les mettrai en download.
Hors ligne
Grâce au message de Marc Cousin, j'ai réussi à compiler l'ensemble sans erreur.
Malheureusement, j'ai malgré tout toujours un segfault :-((
Merci quand-même pour votre aide.
Hors ligne
J'ai finalement créé une fonction unaccent en SQL "pur", comme ceci:
CREATE OR REPLACE FUNCTION unaccent(character varying)
RETURNS character varying AS
$BODY$SELECT to_ascii($1,'latin1') AS result$BODY$
LANGUAGE 'sql' IMMUTABLE
COST 100;
Il y a sans doute quelques failles, mais le résultat me semble actuellement satisfaisant (sauf pour les caratères du genre oe collé...)
Savez-vous comment je pourrais créer un nouveau dictionnaire à partir du dictionnaire français (french_stem) en appliquant cette fonction ?
En effet, si je trouve la solution, je pourrai ensuite reprendre la méthode décrite par Guillaume Lelarge (voir lien dans le 1er message de ce thread)
Hors ligne
Peux-tu donner l'erreur exacte ?
(et merci pour le compliment 
)
Guillaume.
Hors ligne
Bonjour,
Et merci d'avoir pris le temps de s'intéresser à ma demande.
L'erreur apparaissant dans /var/log/message est la suivante:
kernel: postmaster[8680]: segfault at 0000000000000000 rip 00002aaaab3ffd80 rsp 00007fff1a823048 error 4
PS: c'était moi, l'interlocuteur qui évoquait le sujet à Solutions Linux
Hors ligne
Si il y a un segfault, il doit y avoir un core dump quelque part (ou alors il faudrait modifier la ulimit -c de l'utilisateur postgres pour qu'il en génère).
Une fois le core dump obtenu, il faudra le passer dans gdb ... 
Marc.
Hors ligne
Quelles modifications avez-vous fait sur les sources du module de PostgreSQL ?
Guillaume.
Hors ligne
Justement, je n'en ai fait aucune, si ce n'est appliquer le patch, comme suggéré dans un précédent message, pour que la librairie compile.
A priori, je pense que libunacc ne pose pas de problème. En effet, l'exécutable généré (unaccent) semble fonctionner correctement.
Quelques exemples:
unaccent ISO-8859-1 Jérôme => Jerome
unaccent ISO-8859-1 èàçêî => eacei
sachant que l'exécutable utilise bien la librairie précédemment créée:
which unaccent
/usr/local/bin/unaccent
ldd /usr/local/bin/unaccent libunac.so.1 => /usr/local/lib/libunac.so.1 (0x00002aaaaaaad000)
libc.so.6 => /lib64/libc.so.6 (0x0000003f27400000)
/lib64/ld-linux-x86-64.so.2 (0x0000003f27000000)
En d'autres termes, je soupçonnerai plutôt pgunacc, qui compilait pourtant sans problème ?!
Quant à analyser le core dump, c'est au desuus de mes compétences...
Hors ligne
Que donne le ldd sur le module PostgreSQL ? Il trouve bien la libunac ?
Guillaume.
Hors ligne
Oui, pas de problème à ce niveau là.
D'ailleurs, s'il ne la trouve pas (j'ai fait différents essais), on n'obtient pas le même comportement. En effet, dans ce cas là, on a un erreur dès qu'on essaye de créer la fonction. je n'ai plus le message précis en tête, mais il est du style "unable to load libunac.so"
Hors ligne
Bonjour,
Ce n'est pas une question, mais juste un commentaire:
Je viens de migrer ma base en PostgreSQL 9, et le module unaccent marche merveilleusement bien. En plus -ce qui ne gâche rien- il est extrêmement simple d'intégrer une recherche insensible aux accents, ce qui est beaucoup plus conforme aux usages habituels des internautes.
Donc un grand MERCI à tous les développeurs PostgreSQL (et bien entendu, aux "maitres" de ce forum)
Seule information importante (a priori non indiqué dans la documentation):
Pour utiliser ce module, la base doit OBLIGATOIREMENT est encodée en UTF8.
Il semblerait en effet que la fonction ne "supprime" pas les accents pour tout autre encodage, ce qui, dans des cas comme le nôtre, nécessite une certaine vigilance lors de la phase de migration.
Ca aura été pour moi l'occasion de découvrir le SET CLIENT_ENCODING.
Encore merci à tous,
Jérôme
Hors ligne
Pages : 1
