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

Re: exporting raw parser

From: Tatsuo Ishii <ishii(at)postgresql(dot)org>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us
Cc: ishii(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: exporting raw parser
Date: 2010-05-27 02:16:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
> 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

> 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.

That's acceptable at least for pgpool-II. Basically what I need is,
a)SQL statement type, b)target tables, c)target columns(functions)
etc., which seem pretty stable among versions. Even if PostgreSQL
changes the representation of the praser, pgpool-II could ask the
PostgreSQL version and could undertstand the different
representations. Pgpool-II has already done this with the system
catalog changes.

Also good thing is, the parser provides nice APIs to process the parse
tree: raw_expression_tree_walker, outfuncs and macros. Those will
absorb the version difference.

> 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.

From reading README.parser of ecpg, the maintenance problem with ecpg
seems comes from that it needs to modify the grammer. My proposal
does not require the grammer changes. So I don't understand why you
think this would be difficult as ecpg.
Tatsuo Ishii
SRA OSS, Inc. Japan

In response to


pgsql-hackers by date

Next:From: Stephen FrostDate: 2010-05-27 02:19:46
Subject: Re: psql's is_select_command is naive
Previous:From: Stephen FrostDate: 2010-05-27 02:15:12
Subject: Re: ExecutorCheckPerms() hook

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