Bug #37525 funcs_1: <engine>_storedproc.test fail

Description:
Snip of suite/funcs_1/storedproc/storedproc_master.inc:
Attention: The missing 'BEGIN' within the procedure code
           is intended.
--disable_warnings
DROP PROCEDURE IF EXISTS sp1;
--enable_warnings
# missing BEGIN
delimiter //;
--error ER_PARSE_ERROR
CREATE PROCEDURE sp1( cnt int(20) )
    SELECT count(*) into cnt from t2;
    set @count = cnt;
    SELECT @count;
END//
delimiter ;//
--error ER_SP_DOES_NOT_EXIST
CALL sp1( 10 );

Outcome on
mysql-6.0-bugteam last changeset 2008-06-04
mysql-5.1-bugteam last changeset 2008-06-17
-------------------------------------------------
DROP PROCEDURE IF EXISTS sp1;
CREATE PROCEDURE sp1( cnt int(20) )
SELECT count(*) into cnt from t2;
set @count = cnt;
SELECT @count;
END//
ERROR 42000: You have an error in your SQL syntax;
      check the manual .... for the right syntax
      to use near ';
      set @count = cnt;
      SELECT @count;
      END' at line 2
CALL sp1( 10 );
ERROR 42000: PROCEDURE test.sp1 does not exist

Outcome on
mysql-6.0-bugteam last changeset 2008-06-18:
-----------------------------------------------
1. The test aborts because we get
   ER_BAD_FIELD_ERROR instead of ER_PARSE_ERROR
2. If I replace the "--error ER_PARSE_ERROR'
   with '--error ER_BAD_FIELD_ERROR' I get:
DROP PROCEDURE IF EXISTS sp1;
CREATE PROCEDURE sp1( cnt int(20) )
SELECT count(*) into cnt from t2;
set @count = cnt;
SELECT @count;
END//
ERROR 42S22: Unknown column 'cnt' in 'field list'
   <-- IMHO this is a mid size deterioration because
       it is focussed on the column 'cnt'.
       Please remember that the 'BEGIN' is missing.
CALL sp1( 10 );
ERROR 42S02: Table 'test.t2' doesn't exist
   <-- This shows that the procedure exists
       although we got an ERROR on CREATE PROCEDURE.

All above means
- we have a regression
- The problem was most probably introduced by a
  changeset pushed between 2008-06-04 and
  2008-06-18 to mysql-6.0-bugteam.
- IMHO this bug cannot be a duplicate of the several
  open bugs around stored procedures. The other bugs
  existed already when this bug did not exist.

My environment:
- MySQL compiled from source with
  ./BUILD-compile-pentium-debug-max
- Intel Core2Duo (64Bit), OpenSuSE 10.3 (64Bit)

How to repeat:
Either create a test with
   --disable_warnings
   DROP PROCEDURE IF EXISTS sp1;
   --enable_warnings
   # missing BEGIN
   delimiter //;
   --disable_abort_on_error
   CREATE PROCEDURE sp1( cnt int(20) )
       SELECT count(*) into cnt from t2;
       set @count = cnt;
       SELECT @count;
   END//
   delimiter ;//
   CALL sp1( 10 );
or run
./mysql-test-run.pl --skip-ndb \
        --suite=funcs_1 myisam_storedproc \
        --enable-disabled
The "--enable-disabled"
will be needed because I intend to put these
tests into suite/funcs_1/t/disabled.def.
Please note that all <engine>_storedproc
tests and not only the myisam variant are affected.

Suggested fix:
1. It could be discussed if the changed message is
   an important deterioration.
   IMHO the old message pointed more into a useful
   direction. It starts with the next statement 
   ('set @count = cnt;') which is "not allowed" to be
   there if the "begin" is missing.
   The new message mentioning 'cnt' is much less useful.
   But I know the "artificial intelligence' of a
   parser in estimating "what is wrong within a
   statement" is limited.
   Therefore I could live with the new message
   though I liked the old one much more.
2. The creation of the procedure although we got an 
   error message is not acceptable.
   Either the message starts with
   - "ERROR: ..." and the PROCEDURE is not created
      (my first choice)
   or
   - "WARNING: ...." and the PROCEDURE gets created
      (my second choice)
   Somebody could argue that there are several other
   known/documented situations where the MySQL server
   gives in fact a warning (statement changes something)
   but sends a message with from whatever internal
   reason wrong wording (message starts with 'ERROR').
   This argument does not apply here, because we have
   a better behaviour in 5.1 and 6.0 history.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/49200

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/49203

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/49235

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/49236

This is not a regression, but an issue with the test itself.
The test used to "pass" because if was expecting incorrect results,
and because of bug#26030.

In versions where bug#26030 is fixed, the test script now breaks,
since the actual result (correct) does not match the expected result (incorrect).

Pushed in:
- mysql 5.1.28
- mysql 6.0.6

Test case change. No changelog entry needed.

Pushed into 5.1.28  (revid:joerg@mysql.com-20080714105031-88hmr2baz5di9xej) (version source revid:joerg@mysql.com-20080714105031-88hmr2baz5di9xej) (pib:3)