PostgreSQL 9.0.0文書 | ||||
---|---|---|---|---|
前のページ | 巻戻し | 第 41章PL/Perl - Perl手続き言語 | 早送り | 次のページ |
本節ではPL/Perlに影響する設定パラメータを列挙します。 これらのパラメータをPL/Perlがロードされる前に設定するためには、postgresql.conf内のcustom_variable_classesリストに"plperl"を追加する必要があります。
Perlインタプリタが最初に初期化され、plperlまたはplperluでの使用のための準備がなされる前に実行されるperlコードを指定します。 このコードが実行される時にはSPI関数を利用できません。 このコードがエラーで失敗した場合、インタプリタの初期化は中断され、呼び出し元の問い合わせに伝わり、現在のトランザクションまたはサブトランザクションがアボートすることになります。
このPerlコードは単一文字列に制限されます。 長いコードをモジュール化し、on_init文字列でロードすることができます。 以下に例を示します。
plperl.on_init = 'require "plperlinit.pl"' plperl.on_init = 'use lib "/my/app"; use MyApp::PgInit;'
plperl.on_initにより直接または間接的に読み込まれるモジュールはすべて、plperlにより使用可能になります。 これはセキュリティの危険性が発生する可能性があります。 どんなモジュールが読み込まれたかを確認するためには以下を使用します。
DO 'elog(WARNING, join ", ", sort keys %INC)' language plperl;
plperlライブラリがshared_preload_libraries(shared_preload_libraries参照)に含まれている場合、初期化はpostmaster内部で起こります。 この場合、postmasterが不安定になる危険が出てくるため、一層の考慮が必要です。
このパラメータはpostgresql.confまたはサーバのコマンドラインでのみ設定可能です。
これらのパラメータは、plperlまたはplperlu言語が最初にセッション内で使用される時に実行されるPerlコードを指定します。 対応する言語が使用された後にこれらのパラメータを変更しても効果はありません。 このコードを実行する時にはSPI関数は利用できません。 スーパーユーザのみがこの設定を変更することができます。 plperl.on_plperl_init内のPerlコードは信頼できる操作のみを行うことができます。
これらのパラメータの設定の影響は、他でこの言語を使用する前にPerlコードでDOコマンドを実行することと非常によく似ています。 すべての接続で自動的にPerlコードを実行させたい場合や接続が対話式でない場合にこのパラメータは有用です。 スーパーユーザがALTER USER ... SET ...コマンドを実行することで、スーパーユーザ以外でもこのパラメータを使用することができます。 以下に例を示します。
ALTER USER joe SET plperl.on_plperl_init = '$_SHARED{debug} = 1';
コードがエラーで失敗した場合、初期化は中断され、呼び出し元にエラーが伝わります。 その結果現在のトランザクションまたはサブトランザクションはアボートします。 Perl内の変更は取り消されません。 言語が再度使用される時、初期化が繰り返されます。
この2つの設定とplperl.on_init設定の違いは、こちらは%_SHARED変数内に値を設定するなど、信頼される言語または信頼されない言語を指定して設定することに使用できる点です。 対照的にplperl.on_initは、Perlのライブラリ検索パスの設定やPostgreSQLに直接相互関係がないPerlモジュールをロードするなどの場合により有用です。
真の場合、その後のPL/Perl関数のコンパイルはstrictプラグマが有効になります。 このパラメータは現在のセッションでコンパイル済みの関数には影響しません。
現時点では、以下の機能はPL/Perlにありません。 各機能の寄稿を歓迎します。
PL/Perl関数は互いに直接呼び出すことができません。
SPIはまだ完全に実装されていません。
spi_exec_queryを使用して、非常に大規模なデータセットを取り出そうとする場合、これらがすべてメモリ内に保存されることに注意しなければなりません。 上で示した通り、spi_query/spi_fetchrowを使用することで、これを避けることができます。
集合を返す関数が大規模な行セットをreturnを介してPostgreSQLに返す場合、同様の問題が起こります。 前述の通り、この問題もreturn_nextを使用して行毎に返すことで避けることができます。
セッションが正常に終了した時、致命的なエラーによるものでなければ、定義された任意のENDブロックが実行されます。 現在、その他の動作は行われません。 特にファイルハンドルは自動的に吐き出されません。 またオブジェクトも自動的に破棄されません。