1. 22 Jun, 2006 2 commits
    • konstantin@mysql.com's avatar
      Merge mysql.com:/opt/local/work/mysql-5.0-root · 8a2bf1cc
      konstantin@mysql.com authored
      into  mysql.com:/opt/local/work/mysql-5.0-runtime
      8a2bf1cc
    • 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
  2. 21 Jun, 2006 21 commits
  3. 20 Jun, 2006 17 commits