Hi Stewart, > My current work-in-progress looks something like this: > > plugin_init for function registers a struct function with db kernel (for > each function plugin provides. e.g. for COMPRESS/UNCOMPRESS not much > sense just having one in a plugin). > > db kernel adds these functions to hash (currently udf hash). > > struct function contains info such as function name, and a pointer to > create_item, a function that returns a Item*.
Mm, ok. So assuming the function name serves as key in the hash table, this means we can't have overloaded function? I mean, one of the current limitations with UDFs is that they have a fixed return type, and you end up writing multiple UDFs for each case (my_func_as_int(), my_func_as_real()....shudder....) and let the user decide to pick the right one (or commit suicide as I am sure you'll understand). So isn't this the time to fix this and either - make sure the UDF implementor knows what the context expects the return type of the UDF will be and allow the UDF implementor to commit to that choice of return type - allow users to add multiple functions that map to the same SQL function name, each having a different return type > the current way of giving parameters to functions is a bit dumb... so > going to fix that too (push parameters on, how ever many there are, > perhaps have a specifier for max params in Item_func). Mm, maybe it should be called max_args...bikeshed (I though arguments was used more for functions, and parameters being a more general term. anyway, bikeshed) But now you are talking about UDF return type, metadata Is it possible to have a UDF mark itself as deterministic and allow the surrounding parts to take advantage of that? Should probably be a property that is part of the definition of the UDF (i.e. specified at DDL time, not runtime). Currently there is something called UDF_INIT.const_item, which must be the most useless piece of metadata for UDFs, since "I am a constant" is determined at runtime (not DDL time), is a special case of "I am deterministic" anyway, and is not even used by the optimizer. MySQL Source code is full of comments saying "arh...this should be fixed" (I am sure that I can come up with more wishlist items for UDFs, and I am sure other implementors can too.) > a lot of code gets to go away at the same time, which is nice :) > > Another problem to solve is making it easier/nicer to list what plugins > you want to load. What I sorely miss in mysql is a privilege system for UDFs like it exists for stored SQL functions. Now I know that a priv system is not part of the drizzle core, but I think that at some point it would be nice if whatever kind of pluggable privileges make it into drizzle there will be something that regulates access and use of various plugins such as functions. IANA Architect, so I can't really decide if and how this requirement impacts the function subsystem itself, but maybe you can. kind regards, Roland > -- > Stewart Smith ([EMAIL PROTECTED]) > http://www.flamingspork.com/ > > > _______________________________________________ > Mailing list: https://launchpad.net/~drizzle-discuss > Post to : [email protected] > Unsubscribe : https://launchpad.net/~drizzle-discuss > More help : https://help.launchpad.net/ListHelp > > -- Roland Bouman http://rpbouman.blogspot.com/ _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
