> 3] If not, what would be a better mechanism to re-use all the work already > done in postgres for SQL analysis?
One idea would be writing a PostgreSQL function which calls raw_parser() and returns the parse tree as a texual representaion.
Another idea would be pulling out raw_parser() along with related functions from PostgreSQL. pgpool-II (http://pgfoundry.org/projects/pgpool/) has alread done this.
The first idea would mean having a postgres instance always accessible for SQL analysis, which would be an overkill.
I shall check out pgpool-II.
Is there any specific reason why the SQL parsing portion is not exposed - I expect a lot of people to do structure-level analysis of SQL statements, hence I do not really get why it should not be exposed.
Thanks a lot, and thanks for bearing with my questions! :-)