Le module lo ajoute un support des « Large Objects » (aussi appelé LO ou BLOB). Il inclut le type de données lo et un trigger lo_manage.
Un des problèmes avec le pilote JDBC (mais cela affecte aussi le pilote ODBC) est que la spécification suppose que les références aux BLOB (Binary Large OBject) sont stockées dans une table et que, si une entrée est modifiée, le BLOB associé est supprimé de cette base.
Au niveau de PostgreSQL™, ceci n'arrive pas. Les « Large Objects » sont traités comme des objets propres ; une entrée de table peut référencer un « Large Object » par son OID, mais plusieurs tables peuvent référencer le même OID. Donc, le système ne peut pas supprimer un « Large Object » simplement parce que vous avez modifié ou supprimé une entrée contenant son OID.
Ceci n'est pas un problème pour les nouvelles applications spécifiques à PostgreSQL™ mais celles qui existent déjà, qui utilisent JDBC ou ODBC, ne suppriment pas les objets, ceci aboutissant à des « Large Objects » orphelins - des objets qui ne sont référencés par personne et occupant donc un espace disque précieux sans raison.
Le module lo permet de corriger ceci en attachant un trigger aux tables contenant des colonnes de référence des LO. Le trigger fait essentiellement un lo_unlink quand vous supprimez ou modifiez une valeur référence un « Large Object ». Quand vous utilisez ce trigger, vous supposez que, dans toute la base de données, il n'existe qu'une référence d'un « Large Object » référencé dans une colonne contrôlée par un trigger.
Le module fournit aussi un type de données lo, qui est tout simplement un domaine sur le type oid. Il est utile pour différencier les colonnes de la base qui contiennent des références d'objet de ceux qui contiennent des OID sur d'autres choses. Vous n'avez pas besoin d'utiliser le type lo pour utiliser le trigger mais cela facilite le travail pour garder trace des colonnes de votre base de données qui représentent des « Large Objects » que vous gérez avec le trigger. Une rumeur indique aussi que le pilote ODBC a du mal si vous n'utilisez pas le type lo pour les colonnes BLOB.
Voici un exemple d'utilisation :
isn
CREATE TABLE image (title TEXT, raster lo);
CREATE TRIGGER t_raster BEFORE UPDATE OR DELETE ON image
FOR EACH ROW EXECUTE PROCEDURE lo_manage(raster);
Pour chaque colonne qui contiendra des références uniques aux « Large Objects », créez un trigger BEFORE UPDATE OR DELETE trigger, et donnez le nom de la colonne comme argument du trigger. Si vous avez plusieurs colonnes lo dans la même table, créez un trigger séparé pour chacune en vous souvenant de donner un nom différent à chaque trigger sur la même table.
Supprimer une table résultera quand même en des objets orphelins pour tous les objets qu'elle contient, car le trigger n'est pas exécuté. Vous pouvez éviter ceci en faisant précéder le DROP TABLE avec DELETE FROM table.
TRUNCATE a le même comportement.
Si vous avez déjà, ou suspectez avoir, des « Large Objects » orphelins, voir le module vacuumlo(1) (vacuumlo(1)) pour vous aider à les nettoyer. Une bonne idée est d'exécuter vacuumlo occasionnellement pour s'assurer du ménage réalisé par le trigger lo_manage.
Quelques interfaces peuvent créer leur propres tables et n'ajouteront pas les triggers associés. De plus, les utilisateurs peuvent ne pas se rappeler (ou savoir) pour créer les triggers.
Peter Mount <peter@retep.org.uk>