> 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. > 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 English: http://www.sraoss.co.jp/index_en.php Japanese: http://www.sraoss.co.jp -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
