A long-ago-discussed and much-requested feature, "dynamic compound statements", is working at last.
It's been eleven years since the original discussion of dynamic compound statements for MySQL, as you can see by looking at the worklog task on the wayback machine. (As usual, you have to click the "high level architecture" box to see the meat of the specification.) The essential idea is that one can directly enter compound statements like BEGIN ... END and conditional statements like "IF ... END IF" and looping statements like "WHILE ... END WHILE" without needing a CREATE PROCEDURE or CREATE FUNCTION statement.
The advantages are that one can run conditional or complex sequences of statements without needing an EXECUTE privilege, or affecting the database metadata. This has been a popular feature request, as one can see from bug#15037, bug#48777, bug#54000, and bug#61895. and bug#62679.
In 2013 Antony Curtis submitted a patch named "Compound / Anonymous statement blocks for MySQL". (Anonymous blocks is the Oracle terminology.) Apparently he offered it to Oracle but they couldn't agree about the licence terms. The MariaDB people were gladder to get the offer, so it's now in the MariaDB 10.1.1 alpha.
I downloaded it from source. There's a problem with "make install" but it's easy to work around and has nothing to do with Mr Curtis's patch. I had no trouble checking that the feature works as advertised. So, next, I compared the spec with Mr Curtis's implementation.
Spec: Allow BEGIN ... END "compound statements", CASE, IF, LOOP, WHILE, and REPEAT. Implementation: all done. The only significant defect is that BEGIN has to be stated as BEGIN NOT ATOMIC, to avoid confusion with an old non-standard meaning of BEGIN. So "BEGIN DELETE FROM t; END" is illegal. And "label_x: BEGIN DELETE FROM t; END" is illegal. Only "BEGIN NOT ATOMIC DELETE FROM t; END" is legal. It's a slight disappointment that no way was found to handle these little difficulties in the parser.
Spec: internally there will be a temporary anonymous procedure created for every compound statement. Implementation: This didn't happen, at least not in a user-visible way. That's a low-level detail so it doesn't matter.
Spec: there should be no new privilege requirement. Implementation: there is no new privilege requirement.
Spec: the implied routine will have characteristics like MODIFIES SQL DATA and NOT DETERMINISTIC. Implementation: characteristics are irrelevant.
Spec: even if there is an anonymous procedure, it should not be visible to the user in information_schema.routines. Implementation: nothing is visible in information_schema.routines.
Spec: perhaps the statement should be in performance_schema.statements. Implementation: no.
Spec: some statements that are client-specific and are not allowed in stored procedures should not be in dynamic compound statements. Implementation: right. For example "USE database_name" is not allowed.
Spec: it's uncertain whether a dynamic compound statement (which after all is a "statement") should appear as a single statement in the slow log. Implementation: I didn't test this because I don't believe in the slow log; I assumed it doesn't work.
Spec: if @@sql_mode is set within a dynamic compound statement, then it gets restored to its original value when the statement ends. Implementation: yes, it's restored.
Spec: A dynamic compound statement may not contain statements that create or drop or alter routines. Implementation: right, statements like DROP PROCEDURE are illegal.
Spec: a dynamic compound statement cannot be used for a PREPARE statement, and therefore there is no fix for BUG#14115 "Prepare() with compound statements breaks". Supposedly there could be parser-related pitfalls with such syntax. Implementation: PREPARE is allowed. Statements like PREPARE stmt1 FROM 'BEGIN NOT ATOMIC DECLARE v INT; END'// are just fine. This is worrisome, but probably the supposed pitfalls were cleared up long ago.
Spec: SHOW STATUS could have new counters: Com_compound_statement, Com_if, Com_loop, Com_repeat, Com_while. Implementation: No, that's not implemented.
Spec: SHOW PROCESSLIST will show the whole compound statement. Implementation: No, that's not implemented. When I first started the performance_schema design I realized that SHOW PROCESSLIST would eventually become obsolete, so nowadays I think this part of the spec is obsolete.
Given that dynamic compound statements are in DB2 and Oracle 12c and PostgreSQL and now in MariaDB alpha, Oracle/MySQL will look a bit slow if it waits another eleven years to implement them.
But MariaDB 10.1.1 is an early alpha, and nothing is guaranteed in an alpha, so it's too early to say that MariaDB is ahead in this respect.