Jan Wieck wrote:
> The whole parser is a hack that attempts to parse the procedural parts
> of the function but preserving the SQL parts as query strings while
> substituting variables with numbered parameters. That is anything but
> clean. It was the only way I saw at the time of implementation to build
> a parser that automatically supports future changes of the main Postgres
> query language.

I agree the current parser is a hack, but it's difficult to see how else
it could be implemented. One possibility I've mentioned in the past is
to rewrite the main SQL parser by hand (e.g. as a recursive descent
parser), so that we could directly call into the main SQL parser from
the PL/PgSQL parser. I believe that would let us embed SQL in PL/PgSQL
without needing to teach the PL/PgSQL anything about the main SQL
grammar. But of course this has the downside of needing to write and
maintain a recursive descent parser.

Any better ideas?

-Neil

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq