Discussion :

[Aurelienjjj]

Bonjour

J'ai un petit soucis au niveau d'un combo affichage PHP+ Base de données Postgres avec le passage à la version 8.4 de Postgres.

Pour résumer simplement le soucis, j'ai la même page sur 2 serveurs différents, pages php identitiques, base de données identiques, bref, tout identique à peu de chose près: le serveur fonctionnant est un Debian lenny avec Postgres SQL 8.3, le second qui n'affiche pas ( erreur undefined offset, typiquement de BDD ) fonctionne avec Debian Squeeze et Postgres 8.4. Et ce serveur défini, de base, un LC_COLLATE = 'fr_FR.UTF-8' LC_CTYPE = 'fr_FR.UTF-8' dans ma base de données, seule différence notable que j'ai pu trouvé entre ces deux BDD.

Bref, ma question est donc: est-il possible que mes pages PHP, gérant l'UTF8 sans soucis, se retrouvent avec un soucis de compatibilité face à du fr_FR.UTF-8, ou cette norme est-elle totalement rétrocompatible? Et surtout, comment empêcher Postgres de m'ajouter ça automatiquement sur mes BDD, sachant que toutes les bases de données créées se retrouvent automatiquement avec ces attributs, forcer le LC-Collate sur C ou 'none' m'étant interdit.

Merci d'avance

[estofilo]

En 8.4, le choix de la collation est fait à l'initialisation du cluster.
Le paquet debian postgresql choisit a priori la locale par défaut du système.

C'est toutefois changeable en faisant manuellement pg_createcluster avec les bonnes options. Attention au fait que refaire le cluster veut dire perdre toutes les données, il faudra faire un backup/restore si nécessaire.

Il serait sans doute préférable de trouver ce qui ne va pas dans le code plutôt que de s'interdire fr_FR.utf8, mais il est difficile de faire des suppositions là-dessus sans aucun bout de code.

[vmolines]

D'autant que "undefined offset" ne me semble pas être une erreur en provenance de postgre mais plutot de php.

[Aurelienjjj]

Merci de vos réponses. Je suis parvenu à résoudre le problème (qui n'était pas causé par un accès à la base de donnée, mais par un problème de communication avec un serveur XmlRpc couplé à un manque de gestion d'exceptions), cela ne venait donc pas d'une incompatibilité entre UTF-8 et FR_fr.UTF-8.

A priori, je n'ai rien vu à propos d'une telle incompatibilité, donc je suppose que cela doit être compatible. Je le mets en résolu.