So uhmm, use a new parser. Like the one antony wrote in LLVM? :) I mean, we would like to have window functions, CTE, and all those other fun things. SQL-92 is a not relevant anymore. On Tue, Mar 3, 2015 at 6:57 AM, Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Justin!
On Mar 03, Justin Swanhart wrote:
You can't drop a busy proc in production to replace it. Many users would get an error. This is the same reason views have had CoR for so long. So yes it is a big deal!
Okay, I'm happy to know it. My main reason for offering this GSoC project was syntax consistency. Same syntax works identically for all objects, just as a user expects, no gotchas or unpleasant surprises.
Anyway, what I want most are Antony Curtis' stored proc / parser changes (mdev 820 if I'm not mistaken). I am especially interested in table functions and external stored routines.
Yes, I'd be happy to see them in 10.2. It's too early to tell what is going to be there, but I'll certainly put them at the top of list.
I'd also like to discuss window functions too. I've implemented them in shard-query and have ideas about how to implement them in the server, but pluggable parser would be really useful here.
Window functions have a good chance of being in 10.2, it's MDEV-6115. But I don't think that somebody is working on MDEV-6115 yet.
I'm afraid that a pluggable parser is practically impossible to do with bison generated parsers. For a recursive descent parser - yes, but not with bison parsers :(
The best we can do, I think, is to generalize certain parts of the parser by using a generic 'identifier' rule instead of a specific hard-coded keyword token. We've done it a couple of times for plugins:
in CREATE TABLE: https://mariadb.com/kb/en/engine-defined-new-tablefieldindex-attributes/ and in SHOW and FLUSH: https://mariadb.com/kb/en/information-schema-plugins-show-and-flush-statemen...
Regards, Sergei