Re: varchar et encodage - FIN

Bonjour et félicitations pour l'initiative!

"varchar(n) (alias de character varying) et char(n), n'ont que peu d'intérêt
par rapport à text qui permet de stocker des chaînes de caractères de
n'importe quelle longueur, sans pénalité, ni d'espace, ni de performance.
Alors pourquoi s'ennuyer ? Seul autre type texte vraiment intéressant, char
qui n'occupe qu'un byte."
Tout simplement parce que TEXT n'est pas un type SQL standard et que dans
cette mesure, il vaut mieux éviter de l'utiliser, autant que faire se peut !
Il s'agit d'une implémentation propre à PostgreSql, que l'on retrouve malgré
tout dans d'autres types de bases de données. VARCHAR fait partie de la
norme SQL !
SQL permet de codifier les chaînes de caractères dans des formats où chaque
caractères s'exprime sur 2 octets (ASCII, EBCDIC) ou sur 4 octets (Unicode).
La longueur que tu précises, c'est la longueur utile : le nombre de
caractères et non le nombre d'octets !
Mais effectivement si tu as un doute, le plus simple consiste à faire un
petit test simple d'insertion/restitution (INSERT/SELECT)

Cordialement
JM Souchard

-----Message d'origine-----
De : pgsql-fr-generale-owner(at)postgresql(dot)org
[mailto:pgsql-fr-generale-owner(at)postgresql(dot)org
<mailto:pgsql-fr-generale-owner(at)postgresql(dot)org> ] De la part de claude C.
Envoyé : vendredi 12 mai 2006 09:14
À : liste PostgreSql FR
Objet : Re: [pgsql-fr-generale] varchar et encodage - FIN

Bonjour,
Merci à tous pour vos réponses.

> Alors pourquoi s'ennuyer ? Seul autre type texte vraiment intéressant,
> char qui n'occupe qu'un byte.
La question est née parce que ma base est en relation étroite avec d'autres
bases non postgre ainsi qu'avec des entrées en provenance de différentes
sources. Ma liberté est très fortement contrainte. donc :(

Merci encore

Cordialement

Clo

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings