Toru Maesaka wrote:
Hi,
So, all of the above functions would need to be altered to not need the
Session object (all of them can be.) and we'd want to pass in the mem_root
pointer to the parse function instead of the Session object.
Thanks for pointing out the bits and pieces! I guess I can start
looking into this but it might take some time since I haven't quite
mastered this area of the codebase yet. After that, I'll try and
design a structure and API for the Parse Tree that the parser will
work with... though I suspect its not going to be easy.
You'd better get a copy of a fairly recent SQL standard document before
you create this API...
The idea here is that a plugin should not be passed any more information
than it needs to do its job. Clean interfaces ensure that the boundaries of
information are clearly defined and that objects only access those things
about which they "know".
A parser knows the following:
* The input type it expects (typically a string of characters)
* A set of tokens (actually this is more the domain of the lexer, but bear
with me...)
* A set of rules -- the grammar of the language
* The production is should output -- the "parse tree"
What it does *not* need to know about (or care about) is the myriad other
things which are attached to the Session object:
* Status variables
* Configuration variables
* Diagnostics arenas
* Lock information
* Protocol information for communicating with the client socket
* Security contexts (ACL, RBAC)
* Replicator information
* Transaction information
* Much more, as you know...
Keep in mind that you need to propagate error information back from
parsing. I guess you do not want to do that through a thread-specific
THD object, so passing a status object (diagnostics object?) to the
parser may be a good idea.
Thanks,
Roy
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
