I’ve distilled down a problem query to the following example, and I can’t find anything on metalink indicating that this is a known bug, or expected behaviour.
The following script is self contained so anyone could reproduce this, I’m using Oracle 11.2.0.3.0 enterprise 64-bit running on RHEL, queries being submitted via SQL Developer, the same results occur in SQL Plus.
First : create the nested table type.
create type nested_type_test as table of varchar(32);
Second : create a table using the type as the nested type.
create table nested_table_test (
uuid varchar(32)
, some_values nested_type_test
)
NESTED TABLE some_values STORE AS nested_some_values;
Third : create an arbitary table that we will use to create a join statement with.
create table join_table (
uuid varchar(32)
);
Now for some simple SQL statements:
select *
from nested_table_test ntt, table(some_Values) sv;
select *
from nested_table_test ntt, table(some_Values) sv
where ntt.uuid = 'X';
Both work, I havn’t inserted data but for the purposes of this bug / test we do not need to since the issue is a parse issue. Next statement, I add the join to the arbitary table I generated for this purposes.
select *
from nested_table_test ntt, table(some_Values) sv
inner join join_table jt on jt.uuid = ntt.uuid;
This now produces : ORA-00904: "NTT"."UUID": invalid identifier – yet I know that the field exists and could reference it in a where clause. Taking out the TABLE(some_values) clause like this,
select *
from nested_table_test ntt
inner join join_table jt on jt.uuid = ntt.uuid;
and the query works, so I know it is isolated to the existance of the nested table clause within the statement.
If I switch to using a manual join instead of an ANSI join, it then parses and executes again.
select *
from nested_table_test ntt, table(some_Values) sv, join_table jt
where jt.uuid = ntt.uuid;
Alternatively, and even more hack-ish:
select *
from nested_table_test ntt, table(some_Values) sv
inner join join_table jt on 1=1
where jt.uuid = ntt.uuid;
Also parses – so it is not the ntt.uuid itself that is the problem, but where it occurs within the statement that the parser seems to struggle with.
Known bug, Unknown bug or expected behaviour?
Edit : Using CROSS JOIN table(some_values) sv causes a seg fault and a trace file on the server whilst dumping the connection – that one for sure is a bug. It’s also why I’m not in pure ANSI join syntax.
When you are mixing up oracle and ANSI join syntax it’s the expected behavior. ANSI join takes precedence over
,comma join(cross join), parsed from left to right, so it means that thentthas not been joined yet when you were trying to referencentt.uuidcolumn and that is why you might get that error. To that end choose one of the join types. For instance:OR