Roland Bouman 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.
You're absolutely correct, Roland. There could certainly be
finer-grained separation. Your approach would be a logical extension of
separating the parser from the parse rule validation steps.
Cheers!
jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
