One of the problems with the JDBC driver (and this affects the ODBC driver also), is that the specification assumes that references to BLOBs (Binary Large OBjects) are stored within a table, and if that entry is changed, the associated BLOB is deleted from the database. JDBCドライバにおける問題の1つ（ODBCドライバでもこれは影響します）は、規定ではBLOB（バイナリラージオブジェクト）への参照はテーブル内に格納され、その項目が変更されると、関連するBLOBがデータベースから削除されると想定している点です。

As <productname>PostgreSQL</productname> stands, this doesn't occur. Large objects are treated as objects in their own right; a table entry can reference a large object by OID, but there can be multiple table entries referencing the same large object OID, so the system doesn't delete the large object just because you change or remove one such entry. PostgreSQLの立場では、これは起こりません。 ラージオブジェクトは独自の権限をもったオブジェクトとして扱われます。 テーブル項目はOIDによりラージオブジェクトを参照することはできますが、同じラージオブジェクトOIDを参照するテーブル項目を複数持つことも可能です。 このため、システムは、こうした項目を変更または削除したという理由だけでは、ラージオブジェクトを削除しません。

Now this is fine for <productname>PostgreSQL</productname>-specific applications, but standard code using JDBC or ODBC won't delete the objects, resulting in orphan objects &mdash; objects that are not referenced by anything, and simply occupy disk space. さて、これはPostgreSQL固有のアプリケーションでは問題ありませんが、JDBCやODBCを使用する標準的なコードでは、オブジェクトが削除されず、孤児、つまりどこからも参照されずディスクを消費するだけのオブジェクトになります。

The <filename>lo</filename> module allows fixing this by attaching a trigger to tables that contain LO reference columns. The trigger essentially just does a <function>lo_unlink</function> whenever you delete or modify a value referencing a large object. When you use this trigger, you are assuming that there is only one database reference to any large object that is referenced in a trigger-controlled column! loモジュールによりLO参照列を持つテーブルにトリガを付与して、これを解消することができます。 このトリガは基本的には、ラージオブジェクトを参照する値を削除または変更した時常にlo_unlinkを単に行います。 このトリガを使用する時は、単一のデータベースのみがトリガの対象列で参照されるラージオブジェクトを参照することを前提とします。

The module also provides a data type <type>lo</type>, which is really just a <glossterm linkend="glossary-domain">domain</glossterm> over the <type>oid</type> type. This is useful for differentiating database columns that hold large object references from those that are OIDs of other things. You don't have to use the <type>lo</type> type to use the trigger, but it may be convenient to use it to keep track of which columns in your database represent large objects that you are managing with the trigger. It is also rumored that the ODBC driver gets confused if you don't use <type>lo</type> for BLOB columns. また、本モジュールは、単にoid型のドメインに過ぎないloデータ型を提供します。 ラージオブジェクトへの参照を持つデータベース列とこの他のOIDを持つデータベース列との間に違いを持たせるために有用です。 実際このトリガを使用するためにlo型を使用する必要はありません。 しかし、データベース内のどの列がトリガで管理されているラージオブジェクトを示しているかを保持するために、これを使用することは簡便かもしれません。 また、BLOB列でloを使用しない場合、ODBCドライバが混乱してしまうと取りざたされています。

Here's a simple example of usage: 簡単な使用例を示します。

CREATE TABLE image (title text, raster lo);

CREATE TRIGGER t_raster BEFORE UPDATE OR DELETE ON image
    FOR EACH ROW EXECUTE FUNCTION lo_manage(raster);

For each column that will contain unique references to large objects, create a <literal>BEFORE UPDATE OR DELETE</literal> trigger, and give the column name as the sole trigger argument. You can also restrict the trigger to only execute on updates to the column by using <literal>BEFORE UPDATE OF</literal> <replaceable class="parameter">column_name</replaceable>. If you need multiple <type>lo</type> columns in the same table, create a separate trigger for each one, remembering to give a different name to each trigger on the same table. 一意なラージオブジェクト参照を含む列それぞれに対し、BEFORE UPDATE OR DELETEトリガを作成してください。 そして、単一のトリガ引数として列名を指定してください。 BEFORE UPDATE OF column_nameを使って列が更新される時にのみ実行するようトリガを制限することもできます。 同一テーブル上に複数のlo型の列を持たせる必要がある場合、それぞれに対して別のトリガを作成してください。 同一テーブル上の各トリガに別の名前を与えることは忘れないでください。

Peter Mount <peter@retep.org.uk>