I think you raise a number of interesting points here, especially the problem of creating portable, independent modules that at the same time can work together.

The pluggable storage engine interface is a point in case: how can we really use a module with separate features if the SQL dialect that we use to command the module does not change at the same time? It is clear that the current situation in MySQL does not address this: some SQL is engine specific and thus ignored by other engines, and at the same time, some engines have more features than can be addressed through the available SQL constructs. I guess you could argue that your ‘pot of spaghetti’ would solve this, but it seems to me that would still kind of take the shine of the concept of ‘pluggable’ storage engines. I mean, a third party would still need to either make do with all available SQL syntax, or persuade the server developers to add yet more engine specific syntax.

Now I am not saying this to complain or whatever, I am just interested in what people suggest can be done against this situation, and how realistic it is to repair this. I mean, I can imagine that there somehow exists an extensible parser, and that the engine can plug in some new syntax to command it. But how realistic is this? Does anybody know of a system that supports such flexibility for plugins? Another possibility would be to add some clause to statements that are meant to pass through clauses that are interpreted directly by the engine, but then this would still mean that each engine is more than just a datastore, it would still need to ship its own parser to deal with all that.

/me is confused how these problems can be solved.

regards,

Roland.