<URL: https://rt.cpan.org/Ticket/Display.html?id=69573 >
On Tue Oct 02 11:58:41 2012, BBYRD wrote: > On Tue Oct 02 10:56:09 2012, REHSACK wrote: > > I put it into this because of it's all the same reason. Hope it's gonna > > fixed when rewriting SQL::Statement. > > Believe it or not, I am actively developing in this area, and have been > for the last couple of months. I believe that. That was not a comment to your effort nor your skills - it was a comment on the quality of the patch. At first it didn't apply cleanly and second it leads "make test" to fail. Because I know that you active developing, I didn't simply reply "patched with modifications" - I told you it costs me a lot extra effort and hope your next submissions will be better. > Latest DFS levels: > > 1. SQL::Statement needs a new parser. Parser should be something like > SQLT, with multiple in/out parsers. Yes, we all agree on it. I talked to mst and ribasushi about that and I think we found a solution from several kind of views. When ribasushi is back from USA we meet again and talk about some details. > 2. SQLT currently does not work with non-schema statements, so a new > parser project should be created. Parser should borrow from a real, > active RDBMS like PostgreSQL. Additional ones might be - but the one being bundled with SQL::Statement will definitively not. But the design we discussed at YAPC::EU should allow you to write as many parsers supporting as many dialects as your projects require. This was a major goal I wanted to reach (because I understood your requirements - I just disagree fulfilling them in the SQL::Parser). > 3. Pg's parser is written in Bison/C. Need to convert to Perl. > > 4. Successfully converted to Eyapp, but Eyapp is pretty outdated and > inefficient as a parser language. Queries still slow. Would have more > success with a modern top-down parser like Pegex. I'm always open for suggestions. Pegex looks interesting, thanks for the suggestion. But to be true - a real good thing would be some kind of tool which is able to generate Pure-Perl Parser code as well as optional XS support without requiring additional modules at runtime. > 5. Pegex is a rather new language and needs some feature enchantments to > help support the conversion and provide a long-term code base for the > parser. Working with Ingy to shape language to work better with larger > parsers like this. > > Currently at level 5, which I think is about as far down the rabbit hole > as you can go. Have written a quick eyapp2pegex convertor, but like I > said, some shaping of the language needs to happen first to keep things > sane. Let's see what future brings. A token based parser is the next primary goal - this is the thing I agree on. I'd prefer to have that kind of discussion on dbi-dev@ (with probably ribasushi, frew and mst on CC - for Data::Query and SQLT parts of discussion).
