From: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
---|---|
To: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
Cc: | tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: exporting raw parser |
Date: | 2010-06-01 16:27:34 |
Message-ID: | 4C0534F6.6080904@Yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2010-06-01 16:39:20 | Re: [RFC] A tackle to the leaky VIEWs for RLS |
Previous Message | Jan Wieck | 2010-06-01 16:21:57 | Re: Exposing the Xact commit order to the user |