La plupart des systèmes de base de données fournissent un type de données qui peut stocker des données brutes, et PostgreSQL ne fait pas exception. J’utilise le terme données brutes pour signifier que la base de données ne comprend pas la structure ou la signification d’une valeur. En revanche, PostgreSQL comprend la structure et la signification des autres types de données. Par exemple, lorsque vous définissez une colonne ENTIÈRE, PostgreSQL sait que les octets de données que vous placez dans cette colonne sont censés représenter une valeur entière. PostgreSQL sait ce qu’est un entier ?il peut ajouter des entiers, les multiplier, les convertir en et à partir de la forme de chaîne, etc. Les données brutes, en revanche, ne sont-elles qu’une collection de bits?PostgreSQL Tm ne peut en déduire aucune signification dans les données.

PostgreSQL propose le type OCTEA pour stocker des données brutes. Une colonne d’OCTETS peut théoriquement contenir des valeurs de n’importe quelle longueur, mais il semble que la longueur maximale soit de 1 Go.

La taille d’une valeur d’octets est de 4 octets plus le nombre réel d’octets dans la valeur.

Syntaxe pour les valeurs littérales

La saisie d’une valeur d’OCTET peut être un peu délicate. Un littéral d’OCTETS est entré en tant que littéral de chaîne: Il s’agit simplement d’une chaîne de caractères entourée de guillemets simples. Étant donné que, comment entrez-vous une valeur d’OCTET qui inclut un seul guillemet? Si vous revenez à la discussion sur les valeurs littérales de chaîne (plus tôt dans ce chapitre), vous verrez que vous pouvez inclure des caractères spéciaux dans une valeur de chaîne en les échappant. En particulier, une seule citation peut être échappée de l’une des trois manières suivantes:

  • Doublez les guillemets simples (‘Ceci est un guillemet simple »‘)

  • Précédez la citation unique d’une barre oblique inverse (‘Ceci est une citation unique \ »)

  • Incluez plutôt la valeur octale du caractère (‘Ceci est une citation unique \047’)

Il y a deux autres caractères que vous devez échapper lors de la saisie d’octets littéraux. Un octet dont la valeur est nulle (pas le caractère 0, mais l’octet nul) doit être échappé, et le caractère antislash doit être échappé. Vous pouvez échapper n’importe quel caractère en utilisant la forme « \\ddd » (où ddd est un nombre octal). Vous pouvez échapper n’importe quel caractère imprimable en utilisant le formulaire « \\c ». Donc, si vous souhaitez stocker une valeur d’OCTET qui inclut un octet zéro, vous pouvez l’entrer comme ceci:

'This is a zero byte \000'

Si vous souhaitez stocker une valeur d’OCTETS qui inclut une barre oblique inverse, vous pouvez la saisir sous l’une des formes suivantes:

'This is a backslash \\''This is also a backslash \134'

Si vous comparez ces règles aux règles de citation des littéraux de chaînes, vous remarquerez que les littéraux d’octets nécessitent deux fois plus de caractères antislash. C’est une bizarrerie de la conception de l’analyseur PostgreSQL. Les littéraux d’OCTETS sont traités par deux analyseurs différents. L’analyseur principal PostgreSQL voit un littéral d’OCTETS comme un littéral de chaîne (engloutissant le premier ensemble de caractères antislash). Ensuite, l’analyseur d’OCTETS traite le résultat, engloutissant le deuxième jeu de caractères antislash.

Donc, si vous avez une valeur d’OCTETS telle que Ceci est une barre oblique inverse \, vous la citez comme ‘Ceci est une barre oblique inverse \\\\’. Une fois que l’analyseur de chaîne traite cette chaîne, elle a été transformée en ‘Ceci est une barre oblique inverse \\’. L’analyseur d’OCTETS transforme finalement ceci en Ceci est une barre oblique inverse \.

Opérateurs pris en charge

PostgreSQL propose un seul opérateur OCTET : la concaténation. Vous pouvez ajouter une valeur d’OCTETS à une autre valeur d’octets à l’aide de l’opérateur concaténation (||).

Notez que vous ne pouvez pas comparer deux valeurs d’octets, même pour l’égalité / l’inégalité. Vous pouvez, bien sûr, convertir une valeur d’OCTETS en une autre valeur à l’aide de l’opérateur CAST(), ce qui ouvre d’autres opérateurs.

Objets volumineux

Le type de données BYTEA est actuellement limité au stockage de valeurs ne dépassant pas 1 Go. Si vous devez stocker des valeurs plus grandes que celles d’une colonne d’octets, vous pouvez utiliser des objets volumineux. Un objet volumineux est une valeur stockée en dehors d’une table. Par exemple, si vous souhaitez stocker une photo avec chaque ligne de votre table de bandes, vous devez ajouter une colonne O pour contenir une référence au grand objet correspondant:

movies=# ALTER TABLE tapes ADD COLUMN photo_id OID;ALTER

Chaque valeur de la colonne photo_id fait référence à une entrée de la table système pg_largeobject. PostgreSQL fournit une fonction qui chargera un fichier externe (tel qu’un fichier JPEG) dans la table pg_largeobject:

movies=# INSERT INTO tapes VALUESmovies-# (movies(# 'AA-55892',movies(# 'Casablanca',movies(# lo_import('/tmp/casablanca.jpg' )movies(# );

La fonction lo_import() charge le fichier nommé dans pg_largeobject et renvoie une valeur O qui fait référence au grand objet. Maintenant, lorsque vous SÉLECTIONNEZ cette ligne, vous voyez l’ID, pas les bits réels qui composent la photo:

movies=# SELECT * FROM tapes WHERE title = 'Casablanca'; tape_id | title | photo_id----------+------------+---------- MC-68873 | Casablanca | 510699

Si vous souhaitez réécrire la photo dans un fichier, vous pouvez utiliser la fonction lo_export():

movies=# SELECT lo_export( 510699, '/tmp/Casablanca.jpg' ); lo_export----------- 1(1 row)

Pour voir tous les objets volumineux de la base de données actuelle, utilisez la métacommande \lo_list de psql:

movies=# \lo_list Large objects ID | Description--------+------------- 510699 |(1 row)

Vous pouvez supprimer des objets volumineux de votre base de données à l’aide de la fonction lo_unlink():

movies=# SELECT lo_unlink( 510699 ); lo_unlink----------- 1(1 row)movies=# \lo_list Large objects ID | Description----+-------------(0 rows)

Comment obtenez-vous les bits réels derrière l’ID de référence? Tu ne peux pas?du moins pas avec psql. La prise en charge des objets volumineux doit être intégrée à l’application cliente que vous utilisez. psql est un outil orienté texte et n’a aucun moyen d’afficher une photographie, donc le mieux que vous puissiez faire est de regarder les données brutes dans la table pg_largeobject. Quelques applications clientes, telles que Conjectrix Workstation, prennent en charge les objets volumineux et peuvent interpréter correctement les données brutes, dans la plupart des cas.