L'implémentation des objets larges, les coupe en « morceaux » (chunks) stockés dans les lignes de la base de données. Un index B-tree garantit des recherches rapides sur le numéro du morceau lors d'accès aléatoires en lecture et écriture.
Les parties enregistrées pour un « Large Object » n'ont pas besoin d'être contigües. Par exemple, si une application ouvre un nouveau « Large Object », recherche la position 1000000, et y écrit quelques octets, cela ne résulte pas en l'allocation de 1000000 octets de stockage, mais seulement les parties couvrant les octets de données écrites. Néanmoins, une opération de lecture lira des zéros pour tous les emplacements non alloués précédant la dernière partie existante. Cela correspond au comportement habituel des fichiers « peu alloués » dans les systèmes de fichiers Unix.
À partir de PostgreSQL 9.0, les « Large
Objects » ont un propriétaire et un ensemble de droits d'accès pouvant
être gérés en utilisant les commandes GRANT et
REVOKE. Les droits
SELECT
sont requis pour lire un « Large Object », et
les droits UPDATE
sont requis pour écrire ou tronquer.
Seul le propriétaire du « Large Object » ou le propriétaire de la base de
données peut supprimer, ajouter un commentaire ou modifier le propriétaire
d'un « Large Object ».
Pour ajuster le comportement en vue de la compatibilité avec les anciennes
versions, voir le paramètre lo_compat_privileges.