Re^3: DBI: Identify schema objects for a statement

[jZed]

Well ultimatley, the OP is right in the intuition that "only Oracle can parse oracle" (or somesuch). If there isn't a way for it to do that in a way that returns a data structure containing table and view names, then the OP is left with options that will not be complete so MyParse is my thought on the least incomplete of the options. If the alternative is looking through all the SQL by hand, it would at least allow grabbing a lot of the SQL and setting the rest aside to be looked at by hand so it's a win (this also applies to a lesser extent to SQL::Statement). And too, MyParse is, after all an open source module and can therefore possibly be tweaked to handle more Oraclish dialects (isn't that what the bad guys spoke in LOTR?). You're right, MyParse isn't a good solution but it may be the best perl has to offer for this particular task.

And Errto - here's anothr possibility: the Mimer SQL folks put out a very credible (non--perl, also non-free IIRC) SQL parser that might also be a possibility.

update : And here's another thought: the SQL for table and view names is (somewhat) more standard between dialects than other aspects of SQL so errto may be able to get the names out of a partially-parsed structure. E.g given "SELECT foo FROM bar WHERE oracle_only_function(baz) = ?", the parser might be able to tell that the tablename is "bar" even if it barfs on the oracle_only_function().

[rdfield]

with my_alias as (
select * from view1@DBLINK1)
select (select * from view27 v27 where v27.col1 = a.col3)
from (select * from table1) a,
(select * from (select * from my_alias) b,
view c
where c.fk = b.pk) d
where d.fk = a.pk

Table and view names "more standard"?

[jZed]

Compared to say LIMIT clauses or concatenation operators or function names, yes. And what's so nonstandard about the table names in your example? They are all in the format "FROM x".

[rdfield]

The with clause and inline views (in both the select and from clauses) and would cause many problems with anything but a reasonably close match to the SQL engine defined in Parse::RecDescent. I've previously written a tool to cross-reference function and procedure calls across packages which was hard enough to get right, parsing SQL to get a meaningful list of dependent objects would be a whole order of magnitude harder, IMO. I'm not saying it can't be done, I'm just pointing out that just looking for words after "from" wouldn't cut the mustard.