Skip site navigation (1) Skip section navigation (2)

Re: exporting raw parser

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 (view raw or flat)
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

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-05-27 01:45:37
Subject: Re: release notes
Previous:From: KaiGai KoheiDate: 2010-05-27 01:45:10
Subject: Re: ExecutorCheckPerms() hook

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group