Does the parser not support deprecated language keyword "THE" in legacy code? There is a workaround, but...

I've been working with Oracle and Oracle SQL since 1999. This is the first time I've seen 'THE' used in a SQL statement.

Indeed, our parser does not like it

The code below is compiled and executed in Oracle Database 18c (18.3),

but the parser cannot parse it. Probably a problem in the "THE" keyword.

This is a problem if you have a lot of legacy code that already uses such keywords.

But there is a workaround - use keyword "TABLE" instead.

 

Can the grammar rules be extended to support legacy code?

That 'feature' was ONLY available in the very first Oracle 8.0 version and was replaced by the TABLE operator/syntax in Oracle 8.1.7.

The 8.0 doc - see page 4-490

https://docs.oracle.com/cd/A64702_01/doc/server.805/a58225.pdf

The 8.1.7 doc

https://docs.oracle.com/cd/A87860_01/doc/server.817/a85397/state21b.htm#2066025

table_collection_expression::=

 

. . .

table_collection_expression

 

The table_collection_expression lets you inform Oracle that the collection value expression should be treated as a table for purposes of query and DML operations. The collection_expression can be a subquery, a column, a CAST or DECODE expression, a function, or a collection constructor. Regardless of its form, it must return a collection value (that is, a value whose type is nested table or varray). This process of extracting the elements of a collection is called collection unnesting.

. . .

https://community.oracle.com/ Note:  In earlier releases of Oracle, when collection_expression was a subquery, table_collection_expr was expressed as "THE subquery". That usage is now deprecated. 

The 9i doc

https://docs.oracle.com/cd/A91202_01/901_doc/server.901/a90125/statements_103.htm#2073186

 

 

table_collection_expression::=

 

. . .

table_collection_expression

The table_collection_expression lets you inform Oracle that the value of collection_expression should be treated as a table for purposes of query and DML operations. The collection_expression can be a subquery, a column, a built-in function, or a collection constructor. Regardless of its form, it must return a collection value (that is, a value whose type is nested table or varray). This process of extracting the elements of a collection is called collection unnesting.

 

Note: 

In earlier releases of Oracle, when collection_expression was a subquery, table_collection_expression was expressed as "THE subquery". That usage is now deprecated. 

So that 'feature' hasn't been around for almost 30 years now.

This is a problem if you have a lot of legacy code that already uses such keywords..

I seriously doubt if that is a problem at all. Certainly not one of any real interest or issue.

If that is the biggest problem you have in your org consider yourself very fortunate.

I can't imagine you would want to spend YOUR OWN money to modify any current tools to support that 30+ year old syntax.

But there is a workaround - use keyword "TABLE" instead

No - the TABLE operator is the ONLY syntax to use - your orgs 'workaround' is to join the 21st century.

This code still serves well. It is worthy of being parsed

LOL!

It may be 'worthy' of a decent burial but that is about all. I suggest you use this as an excuse to have an office party and give it a good send-off.

Try to see the BIG PICTURE. If you are still using code written for 8.0 functionality you are missing out on a LOT of other improvements in database syntax and functionality.

Many of those improvements were made in the area of collections, sub-queries and bulk processing. It is even likely that with the current DB versions you no longer even need to use pl/sql, collections or bulk processing (assuming you really needed to back then.

That 'legacy code' is more like an albatross around your neck. Get rid of it.

Well if you want you can report that to Oracle support via your MOS account. But I would much rather the Sql Dev team spend its time with more important things.

That syntax was deprecated years ago and although deprecated doesn't mean 'desupported' it should have been desupported long ago.

As I said your org should take it as an opportunity to review ALL of your code (at least the important stuff) since there are likely a lot of opportunities to get much better performance in the latest DB version.

So even though it once was called "raptor", sqldeveloper won't support prehistoric constructs :-)

Since it was first deprecated in 8.1.7 Oracle probably just neglected to ever 'desupport' it.