Sure, fair enough. On Tue, Apr 20, 2010 at 1:37 PM, Monty Taylor <[email protected]> wrote: > On 04/20/2010 08:34 AM, Jay Pipes wrote: >> >> On Tue, Apr 20, 2010 at 11:16 AM, Barry Leslie >> <[email protected]> wrote: > >>> I am happy to do this myself so long as everyone is agreed on what it is >>> I >>> should be doing. Simplest for me would be to implement a "data-filter" >>> plugin API that just does what I need. Ideally it would be better to try >>> and >>> design it so that it was more general and could be used for other >>> purposes >>> such as the ability to create trigger like plugins using the 'pre' and >>> 'post' calls in the "data-filter" plugin. >>> >>> I would propose to model it after the logging plugin and put hooks into >>> it >>> before and after the calls to the engine level ha_write_row(), >>> ha_update_row(), and ha_delete_row() calls in the cursor class as well as >>> pre and post hooks into the StorageEngine dropTable() and renameTable() >> >> This sounds fine to me. My request would be to make the API send >> protobuffer messages that describe the parsed tree, and not pass the >> LEX pointer around. That is welcoming a world of hurt, IMHO. > > I agree about not passing around LEX, but I do not agree about using > protobuffer message unless there is an actual expectation that this object > needs to be serialized either to disk or to the network. Protobuf is great > for serialization, but there is no need for the extra cost if it's just an > internal class. >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
