exporting raw parser
in [PgSql]
|
From: Josh Berkus on 26 May 2010 21:17 > I think those works are essentially a refactoring of existing raw > parser, and will not add performance degration nor maintenance cost. > > Comments? You should call it "libSQL"; who knows, other DB projects might want it. They seem to borrow our parser enough as it is. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 26 May 2010 21:45 Tatsuo Ishii <ishii(a)postgresql.org> writes: > I'm thinking about exporting the raw parser and related modules as a C > library. Though this will not be an immediate benefit of PostgreSQL > itself, it will be a huge benefit for any PostgreSQL > applications/middle ware those need to parse SQL statements. 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. 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. > I think those works are essentially a refactoring of existing raw > parser, and will not add performance degration nor maintenance cost. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tatsuo Ishii on 26 May 2010 22:16 > 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tatsuo Ishii on 26 May 2010 22:28 > I read your proposal says "postgres.exe" will link to "libSQL.dll", > and "pgpool.exe" will also link to the DLL, right? Perhaps. > I think it is reasonable, but I'm not sure what part of postgres > should be in the DLL. Obviously we should avoid code duplication > between the DLL and "postgres.exe". > > > - create an exportable version of memory manager > > - create an exportable exception handling routines(i.e. elog) > > Are there any other issues? For example, > - How to split headers for raw parser nodes? > - Which module do we define T_xxx enumerations and support functions? > (outfuncs, readfuncs, copyfuncs, and equalfuncs) > > The proposal will be acceptable only when all of the technical issues > are solved. The libSQL should also be available in stand-alone. > It should not be a collection of half-baked functions. What do you mean by "should also be available in stand-alone"? If you want more abstract API than "libSQL", you could invent such a thing based on it as much as you like. IMO anything need to parse/operate the raw parse tree should be in libSQL. -- 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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Takahiro Itagaki on 26 May 2010 22:49 Tatsuo Ishii <ishii(a)sraoss.co.jp> wrote: > > The proposal will be acceptable only when all of the technical issues > > are solved. The libSQL should also be available in stand-alone. > > It should not be a collection of half-baked functions. > > What do you mean by "should also be available in stand-alone"? If you > want more abstract API than "libSQL", you could invent such a thing > based on it as much as you like. IMO anything need to parse/operate > the raw parse tree should be in libSQL. My "stand-alone" means libSQL can be used from many modules without duplicated codes. For example, copy routines for raw parse trees should be in the DLL rather than in postgres.exe. Then, we need to consider other products than pgpool. Who will use the dll? If pgpool is the only user, we might not allow to modify core codes only for one usecase. More research other than pgpool is required to decide the interface routines for libSQL. Regards, --- Takahiro Itagaki NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
|
Next
|
Last
Pages: 1 2 Prev: [HACKERS] exporting raw parser Next: [HACKERS] psql's is_select_command is naive |