8.4. Types de données binaires

Le type de données bytea permet de stocker des chaînes binaires; voir Tableau 8-6.

Une chaîne binaire est une séquence d'octets. Les chaînes binaires se distinguent des chaînes de caractères par deux caractéristiques: D'abord, les chaînes binaires permettent de stocker des octets de valeurs zéro, et autres caractères << non imprimables >> (habituellement définis comme des octets en dehors de l'échelle de 32 à 126). Les chaînes de caractères interdisent les octets de valeur zéro et interdisent aussi toute valeur d'octet et séquence d'octets invalide suivant le codage de l'ensemble de caractères sélectionné pour la base de données. Ensuite, les opérations sur les chaînes binaires traitent réellement les octets alors que le traitement de chaînes de caractères dépend de la configuration de la locale. En bref, les chaînes binaires sont appropriées pour le stockage de données que le développeur considère comme des << octets bruts >> alors que les chaînes de caractères sont appropriées pour stocker du texte.

Lors de la saisie de valeurs de type bytea, certaines valeurs d'octets doivent être préparées avec des caractères d'échappement(mais toutes les valeurs peuvent l'être) lorsqu'elles sont font partie d'une chaîne littérale dans une commande SQL. En général, pour échapper un octet, il faut le convertir en nombre octal sur 3 caractères, précédés par deux antislashs. Tableau 8-7 affiche les caractères qui doivent être échappés, et donne les séquences d'échappement possibles.

La nécessité d'échapper les octets << non affichables >> varie en fait suivant les paramétrages de la locale. Quelques fois, vous pouvez vous en sortir sans les échapper. Notez que le résultat de chacun des exemples de Tableau 8-7 était d'une longueur exacte d'un octet, même si la représentation en sortie de l'octet zéro et de l'antislash font plus d'un caractère.

La raison pour laquelle il faut écrire autant de antislashs, comme indiqué dans Tableau 8-7, est qu'une chaîne binaire doit passer à travers deux phases d'analyse dans le serveur PostgreSQL. Le premier antislash de chaque paire est vu comme un caractère d'échappement par l'analyseur de littéral chaîne et est donc consommé, laissant le second antislash de la paire. Le antislash restant est compris par la fonction d'entrée de PostgreSQL comme le début d'une valeur octale sur trois caractères, ou comme l'échappement d'un autre antislash. Par exemple, un littéral de chaînes passé au serveur comme '\\001' devient \001 après être passé à travers l'analyseur de littéral chaîne. Le \001 est envoyé à la fonction d'entrée de bytea, qui le convertit en un octet simple ayant une valeur décimale de 1. Notez que le caractère apostrophe n'est pas traité spécialement par bytea, et suit donc les règles normales pour les littéraux de chaîne. Voir aussi Section 4.1.2.1.)

Les octets de Bytea sont aussi échappés en sortie. En général, chaque octet << non-imprimable >> est converti en équivalent octal sur trois caractères et précédé d'un antislash. La plupart des caractères << imprimables >> sont représentés par leur représentation standard dans le jeu de caractère du client. Les octets de valeur décimale 92 (antislash) ont une représentation alternative spéciale. Les détails sont dans Tableau 8-8.

En fonction du client que vous utilisez pour accéder à PostgreSQL, vous pouvez avoir un travail d'échappement supplémentaire à effectuer pour échapper et déséchapper les chaînes bytea. Par exemple, il se peut que vous deviez échapper les sauts de lignes et retours à la ligne si votre programme client les traduit automatiquement.

Le standard SQL définit un type binaire différent, appelé BLOB ou BINARY LARGE OBJECT. Le format d'entrée est différent de celui du bytea, mais les fonctions et opérateurs fournis sont globalement les mêmes.