Kay Röpke wrote: > Hi! > > On Aug 4, 2008, at 12:27 PM, Daniel Fischer wrote: > >> With antlr, I'd assume? You should use it to replace drizzle's parser, >> so we can get query rewriting on the AST level ;-) > > > The secret plan :) > > In fact, I fully plan to do just that. For a long time now, I wanted to > have the opportunity to modularize the parser code so we can have > multiple ones: > One for raw speed, one for funky things and most importantly one which > is not SQL ;) > > The first step here would be to make a clean API out of the current > (YACC-)action-based calls to the items classes and then separate the > parser out into a module. > > It goes further than that, of course. With a little work the protocol > can be extended to request a certain parser for a request which would > greatly enhance the flexibility of drizzle (and MySQL of course, too). > > This is also the way I intend to bring back "prepared" statements, but > on the client: > Parsing happens on the client and all that gets sent is a flattened > tree. Much simpler to parse because there are no string operations > involved. The downside is that validating a parse tree can be tricky and > allowing it is possibly a security risk. Much easier to provoke crashes > by sending a faulty tree than a faulty string. We'll see.
YES!!! I think parsing on the client and sending a flattened tree is a fantastic idea ... also because it distributes the parsing step further out in the cloud... > I've also wondered about the merit of using a bytecode format for > statements instead of a parse tree, but that's even further down the line. I've also been thinking about that... we should chat at some point. _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
