MySQL Bugs: #6902: Errors in parsing stored procedure parameters

Bug #6902	Errors in parsing stored procedure parameters
Submitted:	1 Dec 2004 0:23	Modified:	7 Dec 2004 18:25
Reporter:	Paul Hyman	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Connector / NET	Severity:	S2 (Serious)
Version:	1.0.2	OS:	Windows (Windows 2000)
Assigned to:	Reggie Burnett	CPU Architecture:	Any

Description:
The parsing of parameters to stored procedures is not robust enough.  In particular, the following problems have been found:

1. Commas are interpreted as parameter separators all the time, so a parameter declaration of:   IN abc DECIMAL(10,2)   will be parsed incorrectly because the comma between the 10 and 2 is interpreted as a separator between two different parameters.

2. Extra tab characters are not treated as whitespace and cause the fields (inout, parameter name, parameter type) to be recognized incorrectly.

Item 2 is easily worked around by removing extra tabs, but number 1 does not appear to have any workaround.

How to repeat:
create a stored procedure with parameters declared as above and try to call it from .NET code.

Suggested fix:
N/A

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

It still does not work with 1.0.6.
See Bug #11386

Also the crude detection of direction and variable name based on the number of tokens is wrong. Consider the parameter "P longtext character set utf8".
It will think that P is the direction and longtext is the name because it has more than 2 words.

You are right.  In 1.0.7 the code has been reworked.  I have added a test case using decimal(19,4) as a parameter and P longtext character set utf8 and they both work ok now. 

Thanks for your reports.

Hi,
even if a enter a comma inside a comment near the parameters, it thinks the text after the comma is a parameter!

Example: 

CREATE PROCEDURE PROC_TEST(
    _ACTION varchar(20),
    _RESULT varchar(10),    /* Generic, result parameter */

This is really bad...

Just to clarify, the correct example would be: 

CREATE PROCEDURE PROC_TEST(
    _ACTION varchar(20),
    _RESULT varchar(10)    /* Generic, result parameter */

...

You're right.  We aren't going to fix this in 5.0 since we are fixing it by building a completely new and much more capable SQL tokenizer.  This is too large a change to introduce into a GA product.