An error occurred fetching the project authors.
  1. 26 Apr, 2006 1 commit
  2. 25 Apr, 2006 1 commit
  3. 21 Apr, 2006 2 commits
    • igor@rurik.mysql.com's avatar
      Post merge fixes · 639e8750
      igor@rurik.mysql.com authored
      639e8750
    • igor@rurik.mysql.com's avatar
      Fixed bug #18767. · fc751415
      igor@rurik.mysql.com authored
      The bug caused wrong result sets for union constructs of the form
      (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
      For such queries order lists were concatenated and limit clause was
      completely neglected. 
      fc751415
  4. 07 Apr, 2006 1 commit
    • kroki@mysql.com's avatar
      Bug#15933: max_used_connections is wrong after FLUSH STATUS if connections are cached · 6222ca41
      kroki@mysql.com authored
      After FLUSH STATUS max_used_connections was reset to 0, and haven't
      been updated while cached threads were reused, until the moment a new
      thread was created.
      
      The first suggested fix from original bug report was implemented:
      
        a) On flushing the status, set max_used_connections to
        threads_connected, not to 0.
      
        b) Check if it is necessary to increment max_used_connections when
        taking a thread from the cache as well as when creating new threads
      6222ca41
  5. 06 Apr, 2006 1 commit
    • svoj@april.(none)'s avatar
      Fix for bug#14945 "Truncate table doesn't reset the auto_increment · 209682e0
      svoj@april.(none) authored
      counter".
      
      When TRUNCATE TABLE was called within an stored procedure the
      auto_increment counter was not reset to 0 even if straight
      TRUNCATE for this table did this.
      
      This fix makes TRUNCATE in stored procedures to be handled exactly
      in the same way as straight TRUNCATE. We achieve this by rolling
      back the fix for bug 8850, which is no longer needed since stored
      procedures don't require prelocked mode anymore (and TRUNCATE is
      not allowed in stored functions or triggers).
      209682e0
  6. 15 Mar, 2006 1 commit
  7. 10 Mar, 2006 2 commits
  8. 09 Mar, 2006 1 commit
  9. 02 Mar, 2006 2 commits
    • anozdrin@mysql.com's avatar
      Implementation of WL#2897: Complete definer support in the stored routines. · fbb59203
      anozdrin@mysql.com authored
      The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION
      statements. Almost all support of definer in stored routines had been already
      done before this patch.
      
      NOTE: this patch changes behaviour of dumping stored routines in mysqldump.
      Before this patch, mysqldump did not dump DEFINER-clause for stored routines
      and this was documented behaviour. In order to get full information about stored
      routines, one should have dumped mysql.proc table. This patch changes this
      behaviour, so that DEFINER-clause is dumped.
      
      Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements
      before this patch, the clause is covered by additional version-specific comments.
      fbb59203
    • anozdrin@mysql.com's avatar
      Fix for BUG#16777: Can not create trigger nor view w/o definer · 302239f3
      anozdrin@mysql.com authored
      if --skip-grant-tables specified.
      
      The problem is that there is a check that prevents creating a definer
      with empty host name.
      
      In --skip-grant-tables mode this check prevents the user from creating a
      trigger/view without explicitly specifying its definer. This happens, because
      in --skip-grant-tables mode CURRENT_USER is ''@''. According to Sanja this
      check was implemented intentionally.
      
      However, according to the MySQL manual it is possible to specify empty host
      name (as well as empty user name). Moreover, the behaviour for stored routines
      is different in this aspect -- we allow them to be created with implicit
      definer.
      
      Based on this, we believe it is OK to change the behaviour for views to be
      similar with the behaviour for stored routines.
      302239f3
  10. 01 Mar, 2006 1 commit
  11. 25 Feb, 2006 1 commit
  12. 24 Feb, 2006 1 commit
  13. 23 Feb, 2006 1 commit
  14. 21 Feb, 2006 1 commit
  15. 26 Jan, 2006 3 commits
  16. 23 Jan, 2006 1 commit
    • aelkin@mysql.com's avatar
      BUG#15699, failure to apply ignore rule for unexisting table. · 0fc8284d
      aelkin@mysql.com authored
        
      Since replication rules execute after `mysql_multi_update_prepare' returns we
      delay to `break' in case this functions returns non-zero (some tables are not found) 
      for to examine if there is an ignore rule for a not-found table. By doing that
      it is guaranteed do/ignore replication rules logically preceed opening table routine.
      0fc8284d
  17. 10 Jan, 2006 3 commits
  18. 05 Jan, 2006 1 commit
    • monty@mysql.com's avatar
      Review fixes of new pushed code · 6e22e29d
      monty@mysql.com authored
      - Fixed tests
      - Optimized new code
      - Fixed some unlikely core dumps
      - Better bug fixes for:
        - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash
        - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
      6e22e29d
  19. 03 Jan, 2006 1 commit
  20. 20 Dec, 2005 1 commit
    • ingo@mysql.com's avatar
      BUG#5390 - problems with merge tables · b0e84cb9
      ingo@mysql.com authored
      Problem #1: INSERT...SELECT, Version for 5.0.
      Extended the unique table check by a check of lock data.
      Merge sub-tables cannot be detected by doing name checks only.
      b0e84cb9
  21. 07 Dec, 2005 4 commits
    • dlenev@mysql.com's avatar
    • ingo@mysql.com's avatar
      BUG#5390 - problems with merge tables · 5aa315e2
      ingo@mysql.com authored
      Problem #1: INSERT...SELECT, Version for 4.1.
      INSERT ... SELECT with the same table on both sides (hidden
      below a MERGE table) does now work by buffering the select result.
      The duplicate detection works now after open_and_lock_tables() 
      on the locks.
      I did not find a test case that failed without the change in
      sql_update.cc. I made the change anyway as it should in theory
      fix a possible MERGE table problem with multi-table update.
      5aa315e2
    • konstantin@mysql.com's avatar
    • anozdrin@mysql.com's avatar
      Patch for WL#2894: Make stored routine variables work · 0ff8f60b
      anozdrin@mysql.com authored
      according to the standard.
      
      The idea is to use Field-classes to implement stored routines
      variables. Also, we should provide facade to Item-hierarchy
      by Item_field class (it is necessary, since SRVs take part
      in expressions).
      
      The patch fixes the following bugs:
        - BUG#8702: Stored Procedures: No Error/Warning shown for inappropriate data 
          type matching; 
       
        - BUG#8768: Functions: For any unsigned data type, -ve values can be passed 
          and returned; 
       
        - BUG#8769: Functions: For Int datatypes, out of range values can be passed 
          and returned; 
       
        - BUG#9078: STORED PROCDURE: Decimal digits are not displayed when we use 
          DECIMAL datatype; 
       
        - BUG#9572: Stored procedures: variable type declarations ignored; 
       
        - BUG#12903: upper function does not work inside a function; 
       
        - BUG#13705: parameters to stored procedures are not verified; 
       
        - BUG#13808: ENUM type stored procedure parameter accepts non-enumerated
          data; 
       
        - BUG#13909: Varchar Stored Procedure Parameter always BINARY string (ignores 
          CHARACTER SET); 
       
        - BUG#14161: Stored procedure cannot retrieve bigint unsigned;
      
        - BUG#14188: BINARY variables have no 0x00 padding;
      
        - BUG#15148: Stored procedure variables accept non-scalar values;
      0ff8f60b
  22. 04 Dec, 2005 1 commit
  23. 03 Dec, 2005 2 commits
  24. 29 Nov, 2005 1 commit
    • ingo@mysql.com's avatar
      BUG#5390 - problems with merge tables · 76861ac6
      ingo@mysql.com authored
      Problem #1: INSERT...SELECT
      INSERT ... SELECT with the same table on both sides (hidden
      below a MERGE table) does now work by buffering the select result.
      The duplicate detection works now after open_and_lock_tables() 
      on the locks.
      I did not find a test case that failed without the change in
      sql_update.cc. I made the change anyway as it should in theory
      fix a possible MERGE table problem with multi-table update.
      76861ac6
  25. 28 Nov, 2005 1 commit
  26. 25 Nov, 2005 1 commit
  27. 24 Nov, 2005 1 commit
  28. 23 Nov, 2005 2 commits