1. 26 Feb, 2008 5 commits
  2. 25 Feb, 2008 1 commit
  3. 22 Feb, 2008 15 commits
  4. 21 Feb, 2008 9 commits
  5. 20 Feb, 2008 5 commits
    • davi@endora.local's avatar
      Merge bk-internal.mysql.com:/home/bk/mysql-5.1-runtime · 2aed47c9
      davi@endora.local authored
      into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime
      2aed47c9
    • davi@endora.local's avatar
      Merge mysql.com:/Users/davi/mysql/bugs/34587-5.1 · 529ed223
      davi@endora.local authored
      into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime
      529ed223
    • davi@mysql.com/endora.local's avatar
      Bug#34587 Creating a view inside a stored procedure leads to a server crash · b9c6b9ec
      davi@mysql.com/endora.local authored
      The problem is that when a stored procedure is being parsed for
      the first execution, the body is copied to a temporary buffer
      which is disregarded sometime after the statement is parsed.
      And during this parsing phase, the rule for CREATE VIEW was
      holding a reference to the string being parsed for use during
      the execution of the CREATE VIEW statement, leading to invalid
      memory access later.
      
      The solution is to allocate and copy the SELECT of a CREATE
      VIEW statement using the thread memory root, which is set to
      the permanent arena of the stored procedure. 
      b9c6b9ec
    • davi@mysql.com/endora.local's avatar
      Bug#32265 Server returns different metadata if prepared statement is used · 04732055
      davi@mysql.com/endora.local authored
      Executing a prepared statement associated with a materialized
      cursor yields to the client a metadata packet with wrong table
      and database names. The problem was occurring because the server
      was sending the the name of the temporary table used by the cursor
      instead of the table name of the original table. The same problem
      occurs when selecting from views, in which case the table name was
      being sent and not the name of the view.
        
      The solution is to fill the list item from the temporary table but
      preserving the table and database names of the original fields. This
      is achieved by tweaking the Select_materialize to accept a pointer to
      the Materialized_cursor class which contains the item list to be filled.
      04732055
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#34337: Server crash when Altering a view using · 57679421
      anozdrin/alik@quad. authored
      a table name.
      
      The problem was that fill_defined_view_parts() did not return
      an error if a table is going to be altered. That happened if
      the table was already in the table cache. In that case,
      open_table() returned non-NULL value (valid TABLE-instance from
      the cache).
      
      The fix is to ensure that an error is thrown even if the table
      is in the cache.
      57679421
  6. 19 Feb, 2008 5 commits