maria-discuss team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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-statements/

Regards,
Sergei