On 5/26/2010 10:16 PM, Tatsuo Ishii wrote:
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.
No, what pgpoo-II needs is a raw parse tree. When it needs info in the
system catalog, it sends SELECT to PostgreSQL. So that would be no
problem.
But doesn't it need that parse tree BEFORE it makes the decision, which
node to execute the query on?
The parser needs the system catalog in order to create a parse tree.
Where would that stand-alone library version of the parser get the
catalog information from? Don't you need to know which user defined
function in the query is volatile?
Jan
--
Anyone who trades liberty for security deserves neither
liberty nor security. -- Benjamin Franklin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
