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
