MySQL Bugs: #19476: SP's in events - documentation request.

Bug #19476	SP's in events - documentation request.
Submitted:	2 May 2006 7:42	Modified:	18 May 2006 5:10
Reporter:	Peter Laursen (Basic Quality Contributor)	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Server	Severity:	S4 (Feature request)
Version:	5.1.x	OS:	Any (any)
Assigned to:		CPU Architecture:	Any

Description:
The manual (+ various articles & whitepapers) describe the use of Stored Procedures in EVENTS.  I miss information about something like this will be handled:

DELIMITER |
CREATE EVENT `TEST`.`CREATEANDDROPME`
ON SCHEDULE EVERY 1 MINUTE 
DO 
BEGIN
CALL MYPROC(); -- this procedure creates table test.ttt and uses it for tempoary purposes ...
DROP TABLE `test`.`ttt`;
END | 
DELIMITER ;

Question is if the EVENT-code will wait for MYPROC() to finish before executing *DROP TABLE*.  That would be quite vital for the workings of the examaple (I know that the *DROP TABLE* with this example could be the last statement in MYPROC .. but there might be other and more complex situations ...).

Probably it is plain to tell for someone who knows about the workings of the server from a code point of view.  I don't.  And many other users do not either!

How to repeat:
well ...

Suggested fix:
This is - at least - a documentation request for the 5.1 manual chapter for events. And if it has not really been considered yet, I also is a request that it is now!

BTW: doesn't this too apply when calling SP's from inside a SP or a TRIGGER ?

Thank you for a documentation request. For me is is obvious that statements inside BEGIN ... END block (in SP or EVENT, or wherever they will be used), separated with ';', are executed sequentially, one after the complete and successfull execution of the previous one. What exactly do you want to see documented?

:-)

Well .. if it is that obvious then it may be a silly request.  You can choose to decide so! 

I just was no sure about if - in a multithreaded environment - call()ing a SP under certain circunmstances would start that SP in a seperate thread where it would run 'on its own'.  I do not have the technical insight into the run-time implementation.

There was a passage in the docs that made me uncertain, but I cannot find it now.
hhmmmm ... your choice what to do.

If the statements that you issue within a given connection did
not execute sequentially, you wouldn't every be able to tell or
expect what they will do.

The MySQL server is multi-threaded, yes, but a given connection
takes up a single thread. Its statements do not execute
asynchronously of one another.

There is no need to fix anything, I think.