バージョンごとのドキュメント一覧

45.8. PL/Perlの内部 #

<title>PL/Perl Under the Hood</title>

45.8.1. 設定 #

<title>Configuration</title>

This section lists configuration parameters that affect <application>PL/Perl</application>. 本節ではPL/Perlに影響する設定パラメータを列挙します。

plperl.on_init (string) #

Specifies Perl code to be executed when a Perl interpreter is first initialized, before it is specialized for use by <literal>plperl</literal> or <literal>plperlu</literal>. The SPI functions are not available when this code is executed. If the code fails with an error it will abort the initialization of the interpreter and propagate out to the calling query, causing the current transaction or subtransaction to be aborted. Perlインタプリタが最初に初期化され、plperlまたはplperluでの使用のための準備がなされる前に実行されるperlコードを指定します。 このコードが実行される時にはSPI関数を利用できません。 このコードがエラーで失敗した場合、インタプリタの初期化は中断され、呼び出し元の問い合わせに伝わり、現在のトランザクションまたはサブトランザクションがアボートすることになります。

The Perl code is limited to a single string. Longer code can be placed into a module and loaded by the <literal>on_init</literal> string. Examples: このPerlコードは単一文字列に制限されます。 長いコードをモジュール化し、on_init文字列でロードすることができます。 以下に例を示します。

plperl.on_init = 'require "plperlinit.pl"'
plperl.on_init = 'use lib "/my/app"; use MyApp::PgInit;'

Any modules loaded by <literal>plperl.on_init</literal>, either directly or indirectly, will be available for use by <literal>plperl</literal>. This may create a security risk. To see what modules have been loaded you can use: plperl.on_initにより直接または間接的に読み込まれるモジュールはすべて、plperlにより使用可能になります。 これはセキュリティの危険性が発生する可能性があります。 どんなモジュールが読み込まれたかを確認するためには以下を使用します。

DO 'elog(WARNING, join ", ", sort keys %INC)' LANGUAGE plperl;

Initialization will happen in the postmaster if the <literal>plperl</literal> library is included in <xref linkend="guc-shared-preload-libraries"/>, in which case extra consideration should be given to the risk of destabilizing the postmaster. The principal reason for making use of this feature is that Perl modules loaded by <literal>plperl.on_init</literal> need be loaded only at postmaster start, and will be instantly available without loading overhead in individual database sessions. However, keep in mind that the overhead is avoided only for the first Perl interpreter used by a database session &mdash; either PL/PerlU, or PL/Perl for the first SQL role that calls a PL/Perl function. Any additional Perl interpreters created in a database session will have to execute <literal>plperl.on_init</literal> afresh. Also, on Windows there will be no savings whatsoever from preloading, since the Perl interpreter created in the postmaster process does not propagate to child processes. plperlライブラリがshared_preload_librariesに含まれている場合、初期化はpostmaster内部で起こります。 この場合、postmasterが不安定になる危険が出てくるため、一層の考慮が必要です。 この機能を使用できるようにした大きな理由は、plperl.on_initでロードされるPerlモジュールはpostmaster起動時点のみでロードされなければならないためです。 このため個々のデータベースセッション内にロードというオーバーヘッドをもたらすことなく即座に利用できるようになります。 しかし、データベースセッションで最初に使用されるPerlインタプリタ(PL/PerlUまたはPL/Perl関数を呼び出す最初のSQLロール用のPL/Perl)に対してのみ、このオーバーヘッドを防ぐことができる点に注意してください。 データベースセッション内でその後に作成されるPerlインタプリタはすべて、新たにplperl.on_initを実行する必要があります。 また、postmasterプロセス内で作成されるPerlインタプリタは子プロセスに伝播されませんので、Windowsにおける事前ロードには何かを節約することはまったくありません。

This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. このパラメータはpostgresql.confファイルまたはサーバのコマンドラインでのみ設定可能です。

plperl.on_plperl_init (string)
plperl.on_plperlu_init (string) #

These parameters specify Perl code to be executed when a Perl interpreter is specialized for <literal>plperl</literal> or <literal>plperlu</literal> respectively. This will happen when a PL/Perl or PL/PerlU function is first executed in a database session, or when an additional interpreter has to be created because the other language is called or a PL/Perl function is called by a new SQL role. This follows any initialization done by <literal>plperl.on_init</literal>. The SPI functions are not available when this code is executed. The Perl code in <literal>plperl.on_plperl_init</literal> is executed after <quote>locking down</quote> the interpreter, and thus it can only perform trusted operations. これらのパラメータはそれぞれ、plperlまたはplperlu用にPerlインタプリタを特化する時に実行されるPerlコードを指定します。 これは、データベースセッション内でPL/PerlまたはPL/PerlU関数が最初に実行される時、または、他の言語が呼び出されたため、あるいは新しいSQLロールでPL/Perl関数が呼び出されたために追加のインタプリタを呼び出す必要があった時に起こります。 この後にplperl.on_initによる初期化が行われます。 このコードを実行する時にはSPI関数は利用できません。 plperl.on_plperl_init内のPerlコードはインタプリタを権限で制限した後に実行されます。 このためPerlコードは信頼できる操作のみを行うことができます。

If the code fails with an error it will abort the initialization and propagate out to the calling query, causing the current transaction or subtransaction to be aborted. Any actions already done within Perl won't be undone; however, that interpreter won't be used again. If the language is used again the initialization will be attempted again within a fresh Perl interpreter. コードがエラーで失敗した場合、初期化は中断され、呼び出し元にエラーが伝わります。 その結果現在のトランザクションまたはサブトランザクションはアボートします。 Perl内ですでに行われた処理は取り消されません。 言語が再度使用される時、初期化は新しいインタプリタの中で再度試行されます。

Only superusers can change these settings. Although these settings can be changed within a session, such changes will not affect Perl interpreters that have already been used to execute functions. スーパーユーザのみがこれらの設定を変更することができます。 これらの設定はセッション内で変更することができますが、このような変更は関数を実行するためにすでに使用されたPerlインタプリタには影響を与えません。

plperl.use_strict (boolean) #

When set true subsequent compilations of PL/Perl functions will have the <literal>strict</literal> pragma enabled. This parameter does not affect functions already compiled in the current session. 真の場合、その後のPL/Perl関数のコンパイルはstrictプラグマが有効になります。 このパラメータは現在のセッションでコンパイル済みの関数には影響しません。

45.8.2. 制限および存在しない機能 #

<title>Limitations and Missing Features</title>

The following features are currently missing from PL/Perl, but they would make welcome contributions. 現時点では、以下の機能はPL/Perlにありません。 各機能の寄稿を歓迎します。

  • PL/Perl functions cannot call each other directly. PL/Perl関数は互いに直接呼び出すことができません。

  • SPI is not yet fully implemented. SPIはまだ完全に実装されていません。

  • If you are fetching very large data sets using <literal>spi_exec_query</literal>, you should be aware that these will all go into memory. You can avoid this by using <literal>spi_query</literal>/<literal>spi_fetchrow</literal> as illustrated earlier. spi_exec_queryを使用して、非常に大規模なデータセットを取り出そうとする場合、これらがすべてメモリ内に保存されることに注意しなければなりません。 上で示した通り、spi_query/spi_fetchrowを使用することで、これを避けることができます。

    A similar problem occurs if a set-returning function passes a large set of rows back to PostgreSQL via <literal>return</literal>. You can avoid this problem too by instead using <literal>return_next</literal> for each row returned, as shown previously. 集合を返す関数が大規模な行セットをreturnを介してPostgreSQLに返す場合、同様の問題が起こります。 前述の通り、この問題もreturn_nextを使用して行毎に返すことで避けることができます。

  • When a session ends normally, not due to a fatal error, any <literal>END</literal> blocks that have been defined are executed. Currently no other actions are performed. Specifically, file handles are not automatically flushed and objects are not automatically destroyed. セッションが正常に終了した時、致命的なエラーによるものでなければ、定義された任意のENDブロックが実行されます。 現在、その他の動作は行われません。 特にファイルハンドルは自動的にフラッシュされません。 またオブジェクトも自動的に破棄されません。