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

PostgreSQL a des fonctionnalités concernant les objets larges, fournissant un accès style flux aux données utilisateurs stockées dans une structure spéciale. L'accès en flux est utile pour travailler avec des valeurs de données trop larges pour être manipuler convenablement en entier.

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 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 les champs TOAST ne peuvent gérer qu'un maximum de 1 Go. De plus, les objets larges peuvent être manipulés élément par élément bien plus facilement que des champs ordinaires de données, donc les limites pratiques sont considérablement différentes.