他のバージョンの文書 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

F.19. lo

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

F.19.1. 原理

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

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

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

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

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

F.19.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トリガを作成してください。 そして、単一のトリガ引数として列名を指定してください。 BEFORE UPDATE OF column_nameを使って列が更新される時にのみ実行するようトリガを制限することもできます。 同一テーブル上に複数のlo型の列を持たせる必要がある場合、それぞれに対して別のトリガを作成してください。 同一テーブル上の各トリガに別の名前を与えることは忘れないでください。

F.19.3. 制限

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

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

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

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

F.19.4. 作者

Peter Mount