• konstantin@mysql.com's avatar
    A fix and a test case for Bug#15217 "Using a SP cursor on a table created · e20898a5
    konstantin@mysql.com authored
     with PREPARE fails with weird error".
    More generally, re-executing a stored procedure with a complex SP cursor query
    could lead to a crash.
    
    The cause of the problem was that SP cursor queries were not optimized 
    properly at first execution: their parse tree belongs to sp_instr_cpush,
    not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the
    cursor was declared, not when it was opened. This led to loss of optimization
    transformations performed at first execution, as sp_instr_copen saw that the
    query is already "EXECUTED" and therefore either not ran first-execution 
    related blocks or wrongly rolled back the transformations caused by 
    first-execution code.
    The fix is to update the state of the parsed tree only when the tree is
    executed, as opposed to when the instruction containing the tree is executed.
    Assignment if i->state is moved to reset_lex_and_exec_core.
    e20898a5
sp.test 124 KB