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.