問題のクエリを次の例に絞り込みましたが、これが既知のバグまたは予想される動作であることを示すメタリンクには何も見つかりません。
次のスクリプトは自己完結型であるため、誰でもこれを再現できます。RHELで実行されているOracle11.2.0.3.0エンタープライズ64ビットを使用しています。クエリはSQLDeveloperを介して送信され、SQLPlusでも同じ結果が得られます。
最初に:ネストされたテーブルタイプを作成します。
create type nested_type_test as table of varchar(32);
2番目:ネストされたタイプとしてタイプを使用してテーブルを作成します。
create table nested_table_test (
uuid varchar(32)
, some_values nested_type_test
)
NESTED TABLE some_values STORE AS nested_some_values;
3番目:結合ステートメントの作成に使用する任意のテーブルを作成します。
create table join_table (
uuid varchar(32)
);
次に、いくつかの単純なSQLステートメントについて説明します。
select *
from nested_table_test ntt, table(some_Values) sv;
select *
from nested_table_test ntt, table(some_Values) sv
where ntt.uuid = 'X';
どちらも機能します。データを挿入していませんが、このバグ/テストの目的では、問題は解析の問題であるため、挿入する必要はありません。次のステートメントでは、この目的のために生成した任意のテーブルに結合を追加します。
select *
from nested_table_test ntt, table(some_Values) sv
inner join join_table jt on jt.uuid = ntt.uuid;
これにより、次のようになります:ORA-00904: "NTT"."UUID": invalid identifier
-それでも、フィールドが存在し、where句で参照できることはわかっています。TABLE(some_values)
このような節を取り出して、
select *
from nested_table_test ntt
inner join join_table jt on jt.uuid = ntt.uuid;
クエリは機能するので、ステートメント内にネストされたテーブル句が存在することとは切り離されていることがわかります。
ANSI結合の代わりに手動結合を使用するように切り替えると、解析して再度実行されます。
select *
from nested_table_test ntt, table(some_Values) sv, join_table jt
where jt.uuid = ntt.uuid;
あるいは、さらにハックっぽい:
select *
from nested_table_test ntt, table(some_Values) sv
inner join join_table jt on 1=1
where jt.uuid = ntt.uuid;
また、解析します-したがってntt.uuid
、問題はそれ自体ではなく、パーサーが苦労しているように見えるステートメント内で発生する場所です。
既知のバグ、未知のバグ、または予想される動作?
編集:使用CROSS JOIN table(some_values) sv
すると、接続のダンプ中にサーバー上でセグメンテーション違反とトレースファイルが発生します。これは確かにバグです。また、純粋なANSI結合構文を使用していないのもそのためです。