lo
モジュールはラージオブジェクト(LOやBLOBとも呼ばれます)保守作業のサポートを提供します。
lo
データ型とlo_manage
トリガが含まれます。
このモジュールは「trusted」と見なされます。つまり、現在のデータベースに対してCREATE
権限を持つ非スーパーユーザがインストールできます。
JDBCドライバにおける問題の1つ(ODBCドライバでもこれは影響します)は、規定ではBLOB(バイナリラージオブジェクト)への参照はテーブル内に格納され、その項目が変更されると、関連する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 FUNCTION lo_manage(raster);
一意なラージオブジェクト参照を含む列それぞれに対し、BEFORE UPDATE OR DELETE
トリガを作成してください。
そして、単一のトリガ引数として列名を指定してください。
BEFORE UPDATE OF
column_name
を使って列が更新される時にのみ実行するようトリガを制限することもできます。
同一テーブル上に複数のlo
型の列を持たせる必要がある場合、それぞれに対して別のトリガを作成してください。
同一テーブル上の各トリガに別の名前を与えることは忘れないでください。
トリガが実行されませんので、テーブル削除により含まれるオブジェクトは孤児化します。
DROP TABLE
の前にDELETE FROM
を行うことで防止することができます。
table
TRUNCATE
も同様の危険があります。
ラージオブジェクトを孤児化させた、または孤児化させた疑いがある場合は、消去するための手助けとなるvacuumloモジュールを参照してください。
lo_manage
トリガのバックネットとしてvacuumloを時々実行することを勧めます。
フロントエンドの中には独自のテーブルを作成するものがあり、その場合、関連するトリガは作成されません。 また、ユーザはトリガを作成することを忘れる(または知らない)かもしれません。
Peter Mount <peter@retep.org.uk>