Re: How to use the SQL parser subsystem
| От | Ravindra Jaju |
|---|---|
| Тема | Re: How to use the SQL parser subsystem |
| Дата | |
| Msg-id | d65123830701040720nd279f42la2a08e035a063893@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: How to use the SQL parser subsystem (Tatsuo Ishii <ishii@postgresql.org>) |
| Список | pgsql-general |
On 1/4/07, Tatsuo Ishii <ishii@postgresql.org> wrote:
> 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! :-)
regards,
jaju
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! :-)
regards,
jaju
В списке pgsql-general по дате отправления: