パイプラインのPL/SQLテーブル関数内で選択を使用することは許可されていますか？

Question

Pipelined関数のドキュメントは、DMLがSQLステートメントで使用されている場合は許可されていないと述べています（通常、 SELECT）、およびほとんどの例では、パイプラインされた関数はデータ生成または変換に使用されます（パラメーターとして顧客を受け入れる）が、DMLステートメントは発行しません。

現在、技術的には、OracleからのエラーなしでSelectsを使用することが可能です（Ora 14551 発生しません）。しかし、私は選択の再現可能な奇妙な行動を経験しています。それでも PRAGMA AUTONOMOUS_TRANSACTION は いいえ 使用されている、行によって取得された行 SELECT 思われる いいえ 常に現在のローカルトランザクションを考慮に入れてください。これは私にとってバグのように感じられます。さらに邪魔なのは、分散トランザクションを使用する場合（たとえば、ローカルトランザクションの代わりにOramtsを介して）、トランザクションが使用されるという事実です。

編集： 結局のところ、奇妙な効果は、クエリのステートメントを持つ一部に関連しているように思われます。クエリのステートメントは機能し、時には機能しません（少なくとも10gで、Oracle Optimizerの現在の気分に応じて）。場合によっては、ORA-32036を取得し、コードをまったく変更せずに再び発生しません。 ORA-32036で時々故障したクエリは、正しいトランザクションを使用できないものであり、パイプラインの関数とは無関係である可能性があるように見えます。

だから私の具体的な質問は次のとおりです。

• 好ましくは公式の声明がありますか？ SELECTパイプラインのテーブル関数のsは許可され、それらのトランザクションコンテキストは何ですか？

• SQLステートメントで使用できる一般的に使用されているクエリをモジュール化する別の方法はありますか（テーブル関数ができるように TABLE())?

• 誰かがそのような行動を経験し、それについてもっと知っているのでしょうか？ Metalinkを調べましたが、残念ながらこのトピックについて具体的なものは見つかりませんでした。

Answer 1

1. 通常、DML制限は変更のみに関係している（更新、削除...）ステートメントに関係しているため、選択は問題ありません。 Oracleから特定の声明を見つけようとします。

2. ビューは、一般的に使用されるクエリをモジュール化する最初のツールです。

3. 関数にはビューよりも欠点があります。別の選択から呼び出された場合、メインセレクトと同じポイントインタイムで実行されません。選択への各呼び出しは一貫していますが、選択はメインSQLではなく機能コードにあるため、一貫性のない結果を返すことができます。これはビューとサブセレクトでは不可能です。大きなステートメントがビューを呼び出す場合、ビューはメインクエリと同じポイントインタイムに構築されます。

アップデート: ：パラメーター化されたクエリに関するコメントについて

パラメーター化されたビューを作成できます。つまり、実行前に設定された変数に依存するビューです。 AskTomの例を次に示します あなたがそれをどのように行うことができるかを示します userenv('client_info') また dbms_session.set_context.