From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: exporting raw parser |
Date: | 2010-05-27 01:45:28 |
Message-ID: | 6125.1274924728@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tatsuo Ishii <ishii(at)postgresql(dot)org> writes:
> I'm thinking about exporting the raw parser and related modules as a C
> library. Though this will not be an immediate benefit of PostgreSQL
> itself, it will be a huge benefit for any PostgreSQL
> applications/middle ware those need to parse SQL statements.
As was already discussed, I don't believe that premise. None of the
applications you cite would be able to make use of the raw parser
output, because it doesn't contain the semantic information they need.
If what you actually meant was the analyzed parse tree, that *might*
serve the need depending on just what is wanted (in particular,
properties that could be affected by the expansion of views or
inlineable functions could still not be determined reliably).
But you can't have that without access to the current system catalog
contents.
In any case there's the serious problem that we simply are not going
to promise that the parser output representation is stable. We've
changed it many times in the past and will do so in the future.
> I think those works are essentially a refactoring of existing raw
> parser, and will not add performance degration nor maintenance cost.
Quite aside from whether the result would be of any use or not, that
opinion is obviously wrong. This would be at least as difficult to
maintain as ecpg ... which has been a enormous time sink.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-05-27 01:45:37 | Re: release notes |
Previous Message | KaiGai Kohei | 2010-05-27 01:45:10 | Re: ExecutorCheckPerms() hook |