Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

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

by rdfield (Priest)
on Aug 30, 2007 at 11:13 UTC ( [id://636052]=note: print w/replies, xml ) Need Help??


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
Table and view names "more standard"?

rdfield

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".
      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

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://636052]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others rifling through the Monastery: (3)
As of 2024-04-24 02:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found