lo

PostgreSQL 9.1.1文書
前のページ | 巻戻し | 付録 F. 追加で提供されるモジュール | 早送り | 次のページ

# F.20. lo

`lo`モジュールはラージオブジェクト（LOやBLOBとも呼ばれます）保守作業のサポートを提供します。 `lo`データ型と`lo_manage`トリガが含まれます。

## F.20.1. 原理

JDBCドライバにおける問題の1つ（ODBCドライバでもこれは影響します）は、規定ではBLOB（バイナリラージオブジェクト）への参照はテーブル内に格納され、その項目が変更されると、関連するBLOBがデータベースから削除されると想定している点です。

PostgreSQLの立場では、これは起こりません。 ラージオブジェクトは独自の権限をもったオブジェクトとして扱われます。 テーブル項目はOIDによりラージオブジェクトを参照することはできますが、同じラージオブジェクトOIDを参照するテーブル項目を複数持つことも可能です。 このため、システムは、こうした項目の変更または削除されたという理由だけでは、ラージオブジェクトを削除しません。

さて、これはPostgreSQL固有のアプリケーションでは問題ありませんが、JDBCやODBCを使用する標準的なコードでは、オブジェクトが削除されず、孤児、つまりどこからも参照されずディスクを消費するだけのオブジェクトになります。

`lo`モジュールによりLO参照列を持つテーブルにトリガを付与して、これを解消することができます。 このトリガは基本的には、ラージオブジェクトを参照する値を削除または変更した時常に`lo_unlink`を単に行います。 このトリガを使用する時は、単一のデータベースのみがトリガの対象列で参照されるラージオブジェクトを参照することを前提とします。

また、本モジュールは、単に`oid`型のドメインに過ぎない`lo`データ型を提供します。 ラージオブジェクトへの参照を持つデータベース列とこの他のOIDを持つデータベース列との間に違いを持たせるために有用です。 実際このトリガを使用するために`lo`型を使用する必要はありません。 しかし、データベース内のどの列がトリガで管理されているラージオブジェクトを示しているかを保持するために、これを使用することは簡便かもしれません。 また、BLOB列で`lo`を使用しない場合、ODBCドライバが混乱してしまうと取りざたされています。

## F.20.2. 使用方法

簡単な使用例を示します。

    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`型の列を持たせる必要がある場合、それぞれに対して別のトリガを作成してください。 同一テーブル上の各トリガに別の名前を与えることは忘れないでください。

## F.20.3. 制限

- トリガが実行されませんので、テーブル削除により含まれるオブジェクトは孤児化します。 `DROP TABLE`の前に`DELETE FROM `table``を行うことで防止することができます。

  `TRUNCATE`も同様の危険があります。

  ラージオブジェクトを孤児化させた、または孤児化させた疑いがある場合は、消去するための手助けとなるvacuumloモジュールを参照してください。 `lo_manage`トリガのバックネットとしてvacuumloを時々実行することを勧めます。

- フロントエンドの中には独自のテーブルを作成するものがあり、その場合、関連するトリガは作成されません。 また、ユーザはトリガを作成することを忘れる（または知らない）かもしれません。

## F.20.4. 作者

Peter Mount `<peter@retep.org.uk>`

前のページ | ホーム | 次のページ
isn | 上に戻る | ltree