Re: exporting raw parser

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

In response to

Browse pgsql-hackers by date

  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