loモジュールはラージオブジェクト（LOやBLOBとも呼ばれます）保守作業のサポートを提供します。
loデータ型とlo_manageトリガが含まれます。
JDBCドライバにおける問題の1つ（ODBCドライバでもこれは影響します）は、規定ではBLOBS（バイナリラージオブジェクト）への参照はテーブル内に格納され、その項目が変更されると、関連するBLOBがデータベースから削除されるると想定している点です。
PostgreSQLの立場では、これは起こりません。 ラージオブジェクトは独自の権限をもったオブジェクトとして扱われます。 テーブル項目はOIDによりラージオブジェクトを参照することはできますが、同じラージオブジェクトOIDを参照するテーブル項目を複数持つことも可能です。 このため、システムは、こうした項目の変更または削除されたという理由だけでは、ラージオブジェクトを削除しません。
さて、これは新規にPostgreSQL固有のアプリケーションでは問題ありませんが、JDBCやODBCを使用する既存のアプリケーションでは、オブジェクトが削除されず、孤児、つまりどこからも参照されないオブジェクトになり、ディスクを消費するだけのもにになります。
loモジュールによりLO参照列を持つテーブルにトリガを付与して、これを解消することができます。
このトリガは基本的には、ラージオブジェクトを参照する値を削除または変更した時常にlo_unlinkを単に行います。
このトリガを使用する時は、単一のデータベースのみがトリガの対象列で参照されるラージオブジェクトを参照することを前提とします。
また、本モジュールは、単にoid型のドメインに過ぎないloデータ型を提供します。 ラージオブジェクトへの参照を持つデータベース列とこの他のOIDを持つデータベース列との間に違いを持たせるために有用です。 実際このトリガを使用するためにlo型を使用する必要はありません。 しかし、データベース内のどの列がトリガで管理されているラージオブジェクトを示しているかを保持するために、これを使用することは簡便かもしれません。 また、BLOB列でloを使用しない場合、ODBCドライバが混乱してしまうと取りざたされています。
簡単な使用例を示します。
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);
一意なラージオブジェクト参照を含む列それぞれに対し、BEFORE UPDATE OR DELETEトリガを作成してください。 そして、単一のトリガ引数として列名を指定してください。 同一テーブル上に複数のlo型の列を持たせる必要がある場合、それぞれに対して別のトリガを作成してください。 同一テーブル上の各トリガに別の名前を与えることは忘れないでください。
トリガが実行されませんので、テーブル削除により含まれるオブジェクトは孤児化します。 DROP TABLEの前にDELETE FROM tableを行うことで防止することができます。
TRUNCATEも同様の危険があります。
ラージオブジェクトを孤児化させた、または孤児化させた疑いがある場合は、消去する補助となるcontrib/vacuumloモジュール（項F.33）を参照してください。
lo_manageトリガのバックネットとしてvacuumloを時々実行することを勧めます。
フロントエンドの中には独自のテーブルを作成するものがあり、その場合、関連するトリガは作成されません。 また、ユーザはトリガを作成することを忘れる（または知らない）かもしれません。
Peter Mount <peter@retep.org.uk>