From: Michael Widenius
Date: October 11 2005 11:11pm
Subject: bk commit into 5.0 tree (pem:1.1997) BUG#7049
List-Archive: http://lists.mysql.com/internals/31003
Message-Id: <17228.18052.675695.746400@gargle.gargle.HOWL>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Hi!

>>>>> "pem" == pem  <pem@stripped> writes:

pem> ChangeSet
pem>   1.1997 05/09/26 18:46:31 pem@stripped +5 -0
pem>   Fixed BUG#7049: Stored procedure CALL errors are ignored
pem>     Search the chain of sp_rcontexts recursively for handlers. If one is found,
pem>     it will be detected in the sp_head::execute() method at the corresponding
pem>     level.

<cut>

pem>   mysql-test/r/sp.result
pem>     1.158 05/09/26 18:46:25 pem@stripped +89 -6
pem>     New test case for BUG#7049.
pem>     Note that the spurious warnings in the BUG#12379 test now are gone (as expected).

pem> +++ 1.158/mysql-test/r/sp.result	2005-09-26 18:46:25 +02:00
pem> @@ -3310,19 +3310,15 @@
pem>  1
pem>  call bug12379_1()|
pem>  bug12379()
pem> +NULL
pem>  42
pem>  42

Why do we get an extra NULL row here?
Is this standard or is this a side effect that we can't give true
errors from SELECT?

Rest of the patch looks ok, it's only the above NULL that I don't
understand. (There is another similar extra NULL in the result, but I
assume it's because of the same reason).

For a reference, the full test case for the above is:

drop table if exists t3|
create table t3 (c1 char(1) primary key not null)|
insert into t3 values('X');
create function bug12379()
returns integer
begin
insert into t3 values('X');
insert into t3 values('X');
return 0;
end|
create procedure bug12379_1()
begin
declare exit handler for sqlexception select 42;
select bug12379();
END|

Regards,
Monty