★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 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

35.4. サーバ側の関数 #

SQLからラージオブジェクトを操作するのに適応したサーバ側の関数を表 35.1に列挙します。

表35.1 SQL向けラージオブジェクト関数

関数

説明

lo_from_bytea ( loid oid, data bytea ) → oid

ラージオブジェクトを作成してそこにdataを格納する。 loidが0であれば、システムが空いているOIDを選び、そうでなければそのOIDが使われる(すでにそのOIDを持つラージオブジェクトがあればエラーになる)。 成功すれば、そのラージオブジェクトのOIDが返される。

lo_from_bytea(0, '\xffffff00')24528

lo_put ( loid oid, offset bigint, data bytea ) → void

ラージオブジェクト内の与えられたオフセットからdataを書き込む。必要であれば、ラージオブジェクトは拡張される。

lo_put(24528, 1, '\xaa')

lo_get ( loid oid [, offset bigint, length integer ] ) → bytea

そこからラージオブジェクトの内容または部分文字列を取り出す。

lo_get(24528, 0, 3)\xffaaff


これまで説明したクライアント側の関数それぞれに対応する、追加のサーバ側の関数があります。 実際、ほとんどのクライアント側の関数は対応するサーバ側の関数に対する単なるインタフェースです。 SQLコマンドからの呼び出しが便利な関数は、lo_creatlo_createlo_unlinklo_importlo_exportです。 これらの使用例を示します。

CREATE TABLE image (
    name            text,
    raster          oid
);


SELECT lo_creat(-1);       -- 新しい空のラージオブジェクトのOIDを返します


SELECT lo_create(43213);   -- OID 43213でラージオブジェクトの生成を試行します


SELECT lo_unlink(173454);  -- OID 173454のラージオブジェクトを削除します

INSERT INTO image (name, raster)
    VALUES ('beautiful image', lo_import('/etc/motd'));


INSERT INTO image (name, raster)  -- 上と同じですが使用するOIDを指定します
    VALUES ('beautiful image', lo_import('/etc/motd', 68583));

SELECT lo_export(image.raster, '/tmp/motd') FROM image
    WHERE name = 'beautiful image';

サーバ側のlo_importおよびlo_export関数の動作はクライアント側の関数とかなり異なります。 この2つの関数はサーバのファイルシステム上のファイルの読み書きを、データベースを所有するユーザの権限で行います。 したがって、デフォルトではこれらの使用はスーパーユーザに限定されています。 対照的に、クライアント側のインポート関数とエクスポート関数はクライアントのファイルシステム上のファイルをクライアントプログラムの権限で読み書きします。 このクライアント側の関数は、対象となるラージオブジェクトの読み出し、書き込み権限を除き、データベース権限を必要としません。

注意

サーバサイドlo_importlo_export関数に対してGRANTを非スーパーユーザに適用することは可能ですが、その結果が意味することについて慎重な考慮が必要です。 そうした権限を持つ悪意のあるユーザは、(たとえば、サーバ設定ファイルを書き換えることによって)容易にその権限を拡張してスーパーユーザになることができるでしょう。 あるいは、そのようにしてデータベーススーパーユーザ権限を取得することなく、サーバのファイルシステムを攻撃することができるでしょう。 したがって、そうした権限を持つロールへのアクセスは、スーパーユーザロールへのアクセスとまったく同様に、注意深く防御されなければなりません。 にもかかわらず、サーバサイドのlo_importあるいはlo_exportを定形業務に使う必要があるなら、完全なスーパーユーザ権限よりは、そうした権限を持つロールを使う方が安全です。 偶発的な間違いから来る被害のリスクを減らすのに役立つからです。

またlo_readおよびlo_writeの機能はサーバサイドの呼び出しを介しても利用することができます。 しかしサーバサイドの関数名はクライアント側のインタフェースとは異なり、アンダースコアが含まれません。 loreadおよびlowriteとしてこれらの関数を呼び出さなければなりません。