> > 2. Query Debugger. I reckon this would only be feasible as a
> > cross-development thing with the postmaster boys-and-girls.
>
>This is one of those things that will go a long way to replicating
>PostgreSQLs parser - i.e., masses of work without a huge benefit.
>
>I would suggest a system that uses the existing parser by attempting to
>execute the query, and interpreting any error messages that are returned
>followed by whatever highlighting of the dodgy syntax can be achieved.
>
>The downside of this is that if a large query is OK, then it will be
>executed. It is possible to prevent this by prepending EXPLAIN, but that
>will only work for SELECT queries.
Yes, I had rather assumed that deep in postmaster there must be decisions
made about the syntax and semantics of a query - the issue was whether
there was any way to hook into these decisions as postmaster is making them
and expose them back to the pgAdmin user to interrupt, breakpoint etc. etc.
Tim.