Hi Elena,

I found the problem while trying to prepare the sql script for you!

The DELIMITER is set to be "//", but I didn't use it for the EVENT.

Thanks so much for your help, and please feel free to remove this bug report!

Kai

Okay, as long as the fix made the problem go away.

I'm still mildly curious about how exactly it looked at the file, because even with the missing delimiter it's not so easy to achieve. But I suppose it's possible.

Hi Elena,

I managed to extract the problematic code in a schema.sql file and attached it to this issue.

Take any database server without a database name "test_db", you can import the schema.sql file and generate a dump file, db_dump.sql:

[kaisong ~]$ mysql -u root -p test_db < schema.sql 
Enter password: 
[kaisong ~]$ mysqldump --routines --triggers --events --single-transaction -u root -p --databases test_db > ./db_dump.sql
Enter password: 

Then, we can see the extra semicolon in the dump file:

[kaisong ~]$ grep EVENT db_dump.sql 
/*!50106 DROP EVENT IF EXISTS `fooEvent` */;
/*!50106 CREATE*/ /*!50117 DEFINER=`root`@`localhost`*/ /*!50106 EVENT `fooEvent` ON SCHEDULE EVERY 1 DAY STARTS '2014-10-21 08:28:26' ON COMPLETION NOT PRESERVE ENABLE DO DELETE FROM Token WHERE DATE(time_end) < CURRENT_DATE; */ ;;

Notice, in the schema.sql file line 22, if I replace the semicolon with "//" delimiter, the problem should be fixed.

Hope this helps with debugging the issue.

Thanks,

Kai

Thanks, it's interesting.
So here is how one can actually do it:

DROP EVENT IF EXISTS fooEvent;
DELIMITER //
CREATE EVENT fooEvent
ON SCHEDULE EVERY 1 DAY
DO
    DELETE FROM Token WHERE DATE(time_end) < CURRENT_DATE;
SELECT 1 //
DELIMITER ;

It's the same in MySQL, too, probably has always been. Not sure that upstream will want to fix it, but at least next time we'll know.

Still, if you want, you can try to file a bug at bugs.mysql.com and see what they say.

After some contemplation, re-opening because it still feels like a bug, albeit minor – a problem with parsing multi-statement queries?
In the example above, if the server considers SELECT being a part of the event body, there should probably be a syntax error; or, if there is no syntax error, SELECT should become a part of the event definition which it's not – when the query is issued, the event is created, while the SELECT gets executed, no errors. So, the server is able to split them properly; but then, it shouldn't put the semicolon in the event body.