1. 19 Oct, 2006 2 commits
    • kroki/tomash@moonlight.intranet's avatar
      Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0 · dea0028c
      kroki/tomash@moonlight.intranet authored
      into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21856
      dea0028c
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21856: Prepared Statements: crash if bad create · 00b2fc6a
      kroki/tomash@moonlight.intranet authored
      When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION
      or CREATE TRIGGER statements with a syntax error in it, the preparation
      would fail with syntax error message, but the memory could be corrupted.
      
      The problem occurred because we switch memroot when parse stored
      routine or trigger definitions, and on parse error we restored the
      original memroot only after performing some memory operations.  In more
      detail:
       - prepared statement would activate its own memory root to parse
         the definition of the stored procedure.
       - SP would reset this memory root with its own memory root to
         parse SP statements
       - a syntax error would happen
       - prepared statement would restore the original memory root
       - stored procedure would restore what it thinks was the original
         memory root, but actually was the statement memory root.
      That led to double free - in destruction of the statement and in
      a next call to mysql_parse().
      
      The solution is to restore memroot right after the failed parsing.
      00b2fc6a
  2. 18 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      Fix for valgrind warning introduced by the fix for bug#21354: · 9fd2c861
      kroki/tomash@moonlight.intranet authored
      (COUNT(*) = 1) not working in SELECT inside prepared statement.
      Note: the warning was introduced in 5.0 and 5.1, 4.1 is OK with the
      original fix.
      
      The problem was that in 5.0 and 5.1 clear() for group functions may
      access hybrid_type member, and this member is initialized in
      fix_fields().
      
      So we should not call clear() from item cleanup() methods, as cleanup()
      may be called for unfixed items.
      9fd2c861
  3. 17 Oct, 2006 2 commits
  4. 12 Oct, 2006 3 commits
    • kroki/tomash@moonlight.intranet's avatar
      Fix after manual merge. · e7c31e81
      kroki/tomash@moonlight.intranet authored
      e7c31e81
    • kroki/tomash@moonlight.intranet's avatar
      Merge moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0 · 9e942999
      kroki/tomash@moonlight.intranet authored
      into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug20953
      9e942999
    • kroki/tomash@moonlight.intranet's avatar
      BUG#20953: create proc with a create view that uses local vars/params · 591c06d4
      kroki/tomash@moonlight.intranet authored
                 should fail to create
      
      The problem was that this type of errors was checked during view
      creation, which doesn't happen when CREATE VIEW is a statement of
      a created stored routine.
      
      The solution is to perform the checks at parse time.  The idea of the
      fix is that the parser checks if a construction just parsed is allowed
      in current circumstances by testing certain flags, and this flags are
      reset for VIEWs.
      
      The side effect of this change is that if the user already have
      such bogus routines, it will now get a error when trying to do
      
        SHOW CREATE PROCEDURE proc;
      
      (and some other) and when trying to execute such routine he will get
      
        ERROR 1457 (HY000): Failed to load routine test.p5. The table mysql.proc is missing, corrupt, or contains bad data (internal code -6)
      
      However there should be very few such users (if any), and they may
      (and should) drop these bogus routines.
      591c06d4
  5. 10 Oct, 2006 10 commits
  6. 09 Oct, 2006 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#21462 (Stored procedures with no arguments require parenthesis) · 6e809b24
      malff/marcsql@weblab.(none) authored
      The syntax of the CALL statement, to invoke a stored procedure, has been
      changed to make the use of parenthesis optional in the argument list.
      With this change, "CALL p;" is equivalent to "CALL p();".
      
      While the SQL spec does not explicitely mandate this syntax, supporting it
      is needed for practical reasons, for integration with JDBC / ODBC connectors.
      
      Also, warnings in the sql/sql_yacc.yy file, which were not reported by Bison 2.1
      but are now reported by Bison 2.2, have been fixed.
      
      The warning found were:
      bison -y -p MYSQL  -d --debug --verbose sql_yacc.yy
      sql_yacc.yy:653.9-18: warning: symbol UNLOCK_SYM redeclared
      sql_yacc.yy:656.9-17: warning: symbol UNTIL_SYM redeclared
      sql_yacc.yy:658.9-18: warning: symbol UPDATE_SYM redeclared
      sql_yacc.yy:5169.11-5174.11: warning: unused value: $2
      sql_yacc.yy:5208.11-5220.11: warning: unused value: $5
      sql_yacc.yy:5221.11-5234.11: warning: unused value: $5
      conflicts: 249 shift/reduce
      
      "unused value: $2" correspond to the $$=$1 assignment in the 1st {} block
      in table_ref -> join_table {} {},
      which does not procude a result ($$) for the rule but an intermediate $2
      value for the action instead.
      "unused value: $5" are similar, with $$ assignments in {} actions blocks
      which are not for the final reduce.
      6e809b24
  7. 08 Oct, 2006 3 commits
  8. 06 Oct, 2006 9 commits
  9. 05 Oct, 2006 5 commits
  10. 04 Oct, 2006 1 commit
  11. 03 Oct, 2006 3 commits