Le type de données bytea permet de stocker des chaînes binaires ; voir le Tableau 8.6, « Types de données binaires ».

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 : tout d'abord, les chaînes binaires permettent de stocker des octets de valeurs zéro ainsi que les 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 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. Le Tableau 8.7, « bytea Octets littéraux à échapper » 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. Quelque fois, vous pouvez vous en sortir sans les échapper. Notez que le résultat de chacun des exemples du Tableau 8.7, « bytea Octets littéraux à échapper » é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 d'antislashs, comme indiqué dans le Tableau 8.7, « bytea Octets littéraux à échapper », 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 chaîne et est donc consommé, laissant le second antislash de la paire. L'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 chaîne passé au serveur comme '\\001' devient \001 après être passé au travers de 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 les règles normales pour les littéraux de chaîne. Voir aussi la Section 4.1.2.1, « Constantes de chaînes ».

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 autre représentation spéciale. Les détails sont dans le Tableau 8.8, « Octets échappés en sortie pour bytea ».

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.