Hmmm... On Sun, Mar 1, 2009 at 1:28 PM, Roland Bouman <[email protected]> wrote: > Hi all! > > On Sun, Mar 1, 2009 at 5:11 PM, Jay Pipes <[email protected]> wrote: >> * The production is should output -- the "parse tree" > > ... > >> I'm thinking a goal for the *interface* would be something like the >> following for a C plugin: >> >> bool (*sql_parse) >> (ParseTree* node, MEM_ROOT *alloc, const char *query, const size_t >> query_len); >> >> and this for a C++ plugin: >> >> class SqlParseEvent >> { >> public: >> bool operator()(ParseTree *node, MEM_ROOT *root, std::string query); >> } >> >> The basic idea being that the parser should focus on *parsing* and nothing >> else. Just parse the query into a tree and pass it back to the caller. > > I'm just curious.... > > You seem to imply that parsing involves building the parse tree. > Logically, parsing and building the parse tree could be separated > (event based parser, where the parser signals parse events and a > listener does something interesting such as building the parse tree) > > I'm just curious if there is some rule ofthe tumb that determines > whether it'd be better to integrate building the parse tree rather > than abstract it using an event-based parser design.
I think Jim kind of said this already, but I'll say it a different way. You're probably confusing parsing with tokenizing and lexing and all kinds of other stuff. Designing a query execution plan from the parse tree, now thats a different matter... might be best not to refer to the MySQL codebase for any inspiration on this ;-) _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
