On Thu, 2005-07-14 at 14:32 +1000, Neil Conway wrote: > Alvaro Herrera wrote: > > I don't think you can use just plpgsql's parser. ... it > > relies on the main backend parser > > If you're content to treat expressions and SQL queries as > opaque strings, you shouldn't need to concern yourself with the main SQL > parser. Treating queries as terminal nodes in the parse tree would be fine as a starting point. > > The main parser depends (at least) on the List handling and memory > > handling. > > The PL/PgSQL parser also depends on these, although to a lesser degree. I suppose these dependencies are okay as long as I can just link my parser to a library (e.g. src/pl/plpgsql/src/libplpgsql.so) and everything magically works. My fantasy here is to perform some straightforward surgery and bring to life an executable that accepts PL/pgSQL code (e.g. as text on STDIN) and creates a parse tree in memory. The stuff in src/pl/plpgsql/src/ looked like a good starting point. gram.y and scan.l are there. pl_funcs.c has some cool-looking "dump*" functions. Now, can this stuff be "straightforwardly" hacked into a program that gets its PL/pgSQL source code from STDIN or from a text file, instead of from the "AS" clause of a "CREATE FUNCTION" statement? My goal is to automate (as much as possible) the conversion of Oracle PL/SQL stored procedures into PL/pgSQL. Up to this point I've been exploring Perl as a tool for this, but things are getting a bit thick for me to rely on Perl regexes as my most-powerful weapon. Instead of growing my Perl stuff to look more and more like a parser, I went looking for a parser, and ended up in src/pl/plpgslq/src. ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
