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.