ステートメントの処理時にデータベースで関数、メソッド、 およびデータ・タイプを解決する場合がありますが、 データベース・マネージャーはこの解決を繰り返すことができなければなりません。 これは、以下の場合に当てはまります。
パッケージ内の静的 DML ステートメントの場合、関数、メソッド、 およびデータ・タイプの参照はバインド操作時に解決されます。 視点、トリガー、検査制約の中にある関数、メソッド、およびデータ・タイプの参照は、 データベース・オブジェクトの作成時に解決されます。
これらのオブジェクトに含まれている関数またはメソッド参照のいずれかで、 2 度目の関数またはメソッド解決が実行される場合、一致の度合いは高くても、 実際の実行可能プログラムには異なる操作を実行させるシグニチャーを持った新しい関数またはメソッドが追加されていると、 動作が変わってしまうおそれがあります。 同様に、 これらのオブジェクトに含まれているデータ・タイプのいずれかで 2 度目の関数解決が実行される場合、 他のスキーマにあるのと同じ名前 (SQL パスにも存在している) で新しいデータ・タイプが追加されていると、 動作が変わってしまうおそれがあります。 この問題を回避するため、データベース・マネージャーは 保守的バインド・セマンティクス という概念を適用します。 この概念は、関数やデータ・タイプの参照を解決するときに、 バインド時と同じ SQL パスが使用されるようにします。 また、解決時に考慮される関数 31 、 メソッドおよびデータ・タイプの作成タイム・スタンプが、 ステートメントをバインドした時刻よりも遅くならないようにします。 32 このようにして、関数、メソッド、およびデータ・タイプのうち、 ステートメントを最初に処理したときの解決時に考慮されたものだけが考慮されるようにします。 したがって、保守的バインド・セマンティクスが適用される場合、 後から作成された関数、メソッド、およびデータ・タイプは考慮されません。
パッケージ内の静的 DML の場合、パッケージの再バインドは暗黙的に行われるか、 REBIND コマンド (またはこれに対応する API) または BIND コマンド (またはこれに対応する API) を明示的に発行することによって行われます。 暗黙的な再バインドでは、常に保守的バインド・セマンティクスを適用して、 関数、メソッド、およびデータ・タイプの解決が実行されます。 REBIND コマンドを使用する場合は、 保守的バインド・セマンティクスを適用して解決するか (RESOLVE CONSERVATIVE オプション)、 それとも新しい関数、メソッド、およびデータ・タイプを考慮して解決するか (デフォルトまたは RESOLVE ANY オプションを使用) を選択できます。