Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
je viens d'installer pg 9.1.5 et j'espérais que l'impossibilité de saisir des caractères accentués dans psql (sous ubuntu 12.04) aurait disparu. Hélas, il n'en est rien.
Ce n'est pas très grave (l'affichage est bon et je peux saisir autrement) mais un peu ennuyeux.
Savez-vous si ce sera corrigé en 9.2 ? Il me semble avoir lu un article disant que ce n'était pas vraiment pg , mais une bibliothèque utilisée
pour pouvoir rappeler les dernières commandes (readline ? readlinen ?) .
Quelqu'un aurait-il des lumières sur cette question ?
Merci
Hors ligne
Bonjour,
qu'entendez-vous par impossibilité de saisir des caractères accentués ? faire select 'é' ne fonctionne pas ou sagit-il d'autre chose ?
Votre locale est-elle la même que celle de votre base de donnée ? Je n'ai jamais eu ce problème personnellement.
Dernière modification par rjuju (21/08/2012 19:20:32)
Julien.
https://rjuju.github.io/
Hors ligne
Exactement . select 'é' ne marche pas, ou update xxx set xx='é'. Dans un fichier sql, pas de souci.
J'avais lu un article là-dessus, mais je n'arrive plus à le retrouver.
Hors ligne
La première chose est de vérifier que la locale utilisée dans le terminal est bien compatible avec des accents.
Voir le résultat sous shell avant de lancer psql de la commande:
locale -aMais il se peut aussi que l'impossibilité de saisir des accents vienne de ce problème:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608442
Ubuntu utilise les mêmes packages que Debian pour PostgreSQL et subit généralement les mêmes bugs.
En appelant psql comme ça:
LD_PRELOAD=lib/libreadline.so.5 psql [options]ça doit contourner le problème. Mais en principe c'est déjà fait automatiquement si le package postgresql-common a une version supérieure à 114 (EDIT: et que libreadline est installé)
Pour vérifier, voir le résultat de:
dpkg -l postgresql-commonDernière modification par dverite (21/08/2012 23:51:16)
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
C'est bien l'article que j'avais lu.
Voici les résultats des commandes :
locale -a
C
C.UTF-8
en_US.utf8
fr_FR
fr_FR@euro
fr_FR.iso88591
fr_FR.iso885915@euro
fr_FR.utf8
fr_FR.utf8@euro
POSIXLD_PRELOAD=lib/libreadline.so.5 psql
ERROR: ld.so: object 'lib/libreadline.so.5' from LD_PRELOAD cannot be preloaded: ignored.pkg -l postgresql-common
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom Version Description
+++-==================================================-==================================================-====================================================================================================================
ii postgresql-common 129 PostgreSQL database-cluster managerAprès ça , j'ai installé le paquet libreadline-dev et cherché la librairie.
Ca marche en faisant : LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libreadline.so psql
J'ai fait un alias "psqlx=LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libreadline.so psql"
Sur le fond du problème, pg doit continuer à utiliser libedit pour une histoire de licence, si j'ai bien compris le rapport de bug ?
Pas de solution plus élégante en vue ?
Hors ligne
LD_PRELOAD=lib/libreadline.so.5 psql
ERROR: ld.so: object 'lib/libreadline.so.5' from LD_PRELOAD cannot be preloaded: ignored.
C'est parce qu'il mangue le / initial au début de /lib...
Mais de toute façon, pour le LD_PRELOAD, avec la version 129 de postgresql-common, en principe ça le fait déjà automatiquement.
Il faut simplement que le package libreadline5 soit installé. C'est apparemment la solution la moins inélégante trouvée en attendant que libedit soit assez évolué pour bien gérer les accents.
Par ailleurs les locales installées comprennent à la fois de l'ISO-LATIN et de l'UTF8 en plus de la locale C qui ne gère pas les accents, ce qui est courant pour un système français mais ça oblige à bien vérifier que le terminal est configuré dans la même locale que psql (faire locale tout seul sans -a pour vérifier la locale courante sous le shell, puis show client_encoding sous psql pour voir si c'est compatible).
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Pages : 1