in reply to
Re^2: DBI: Identify schema objects for a statement
in thread DBI: Identify schema objects for a statement
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.
: 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().