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

in reply to Re^3: DBI: Identify schema objects for a statement
in thread DBI: Identify schema objects for a statement

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
[download]

Table and view names "more standard"?

rdfield

Comment on Re^4: DBI: Identify schema objects for a statement Download Code

Replies are listed 'Best First'.
Re^5: DBI: Identify schema objects for a statement by jZed (Prior) on Aug 30, 2007 at 15:36 UTC
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".	[reply]
Re^6: DBI: Identify schema objects for a statement by rdfield (Priest) on Aug 31, 2007 at 10:56 UTC
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. rdfield	[reply]

In Section Seekers of Perl Wisdom