Re: Standalone Parser for PL/pgSQL

From: Richard_D_Levine(at)raytheon(dot)com
To: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Standalone Parser for PL/pgSQL
Date: 2005-07-14 16:07:35
Message-ID: OF859361DA.1E1FDCA8-ON0525703E.0057C11B-0525703E.00589603@ftw.us.ray.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

pgsql-general-owner(at)postgresql(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2005-07-14 16:07:58 Re: ERROR: could not open relation
Previous Message Reid Thompson 2005-07-14 15:53:54 Re: DB/clog corruption