Chapitre 28. Objets larges

Table des matières
28.1. Historique
28.2. Fonctionnalités d'implémentation
28.3. Interfaces client
28.3.1. Créer un objet large
28.3.2. Importer un objet large
28.3.3. Exporter un objet large
28.3.4. Ouvrir un objet large existant
28.3.5. Écrire des données dans un objet large
28.3.6. Lire des données à partir d'un objet large
28.3.7. Recherche dans un objet large
28.3.8. Obtenir la position de recherche d'un objet large
28.3.9. Fermer un descripteur d'objet large
28.3.10. Supprimer un objet large
28.4. Fonctions du côté serveur
28.5. Programme d'exemple

Dans les versions de PostgreSQL antérieures à la 7.1, la taille de toute ligne dans la base de données ne pouvait pas excéder la taille d'une page de données. Comme la taille d'une page de données est de 8192 octets (par défaut, mais cela peut être augmenté jusqu'à un maximum de 32768), la limite maximale sur la taille d'une donnée était assez basse. Pour supporter le stockage de valeurs atomiques plus importantes, PostgreSQL a fourni et continue de fournir une interface pour les objets larges. Cette interface propose un accès orienté fichier à des données utilisateurs stockées dans une structure spécifique aux objets larges.

Ce chapitre décrit l'implémentation, la programmation et les interfaces du langage de requêtes pour les données de type objet large dans PostgreSQL. Nous utilisons la bibliothèque C libpq pour les exemples de ce chapitre mais la plupart des interfaces natives de programmation de PostgreSQL supportent des fonctionnalités équivalentes. D'autres interfaces pourraient utiliser l'interface des objets larges en interne pour fournir un support générique des valeurs larges. Ceci n'est pas décrit ici.

28.1. Historique

POSTGRES 4.2, le prédécesseur indirect de PostgreSQL, supportait trois implémentations standards des objets larges : par des fichiers externes au serveur POSTGRES, par des fichiers externes gérés par le serveur POSTGRES et par des données stockées dans la base de données POSTGRES. Ceci a causé une énorme confusion parmi les utilisateurs. Du coup, seul le support des objets larges en tant que donnée stockée dans la base de données a été conservé dans PostgreSQL. Bien qu'il soit plus lent en accès, il fournit une intégrité stricte des données. Pour des raisons historiques, le schéma de stockage est référencé comme Inversion large objects (vous apercevrez le terme inversion utilisé occasionnellement pour signifier aussi un objet large). Depuis PostgreSQL 7.1, tous les objets larges sont placés dans une table système appelée pg_largeobject.

PostgreSQL 7.1 a introduit un mécanisme (nom de code << TOAST >>) qui permet à des lignes de données d'être bien plus larges que des pages de données individuelles. Ceci rend l'interface des objets larges partiellement obsolète. Un des avantages restant de l'interface des objets larges est qu'il permet des tailles importantes, avec un maximum de 2 Go alors que TOAST ne peut gérer qu'un maximum de 1 Go.