List:Internals« Previous MessageNext Message »
From:Per-Erik Martin Date:October 13 2005 9:57am
Subject:Re: bk commit into 5.0 tree (pem:1.1997) BUG#7049
View as plain text  
Michael Widenius writes:
> 
> 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).

Yes, I think it's a side effect of the way error handling works in select.

Before this patch, no NULL was returned from the select, but instead a
"Warnings: Error 1062 Duplicate entry 'X' for key 1" was set, *and* the
exception handler caught (because the "select" itself returned an error).
This was a somewhat inconsistent behaviour.

Now the handler catches the error from the "insert" in the function
directly (which it should; this is what the bug is about), but then
"select" returns a NULL instead (without a warning).

This is probably inconsistent as well, but in a different way, but I
think it's a sepearate problem. (The already known issues with error
handling in "select".)

> 
> 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|

    /pem

Thread
bk commit into 5.0 tree (pem:1.1997) BUG#7049pem26 Sep
  • bk commit into 5.0 tree (pem:1.1997) BUG#7049Michael Widenius13 Oct
    • Re: bk commit into 5.0 tree (pem:1.1997) BUG#7049Per-Erik Martin13 Oct