pgsql-general-owner@postgresql.org wrote on 07/14/2005 10:38:43 AM:
> 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.
Ya know, what would be *totally* cool is to implement Oracle PL/SQL syntax
transparently in PostgreSQL. You just can't do packages in PL/pgSQL. You
can mimic them with schemas, but there are things that must be done
differently, and probably more slowly, like package body global constants
and variables. If I were doing it, which I'm not, I would implement
Oracle's quoting and not the PL/pgSQL quoting paradigm. Man it's painful.
Understandable, due to the many languages supported, but painful
nonetheless.
> 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