An error occurred fetching the project authors.
  1. 27 Mar, 2007 1 commit
  2. 09 Mar, 2007 1 commit
  3. 07 Mar, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#25373: Stored functions wasn't compared correctly which leads to a wrong · b81b814c
      evgen@moonbone.local authored
      result.
      
      For built-in functions like sqrt() function names are hard-coded and can be
      compared by pointer. But this isn't the case for a used-defined stored
      functions - names there are dynamical and should be compared as strings.
      
      Now the Item_func::eq() function employs my_strcasecmp() function to compare
      used-defined stored functions names.
      b81b814c
  4. 02 Mar, 2007 1 commit
  5. 23 Feb, 2007 1 commit
    • cbell/Chuck@mysql_cab_desk.'s avatar
      BUG#20141 "User-defined variables are not replicated properly for SF/ · 4c6ced9f
      cbell/Chuck@mysql_cab_desk. authored
                 Triggers in SBR mode."
      BUG#14914 "SP: Uses of session variables in routines are not always
                 replicated"
      BUG#25167 "Dupl. usage of user-variables in trigger/function is not
                 replicated correctly"
      
      User-defined variables used inside of stored functions/triggers in
      statements which did not update tables directly were not replicated.
      We also had problems with replication of user-defined variables which
      were used in triggers (or stored functions called from table-updating
      statements) more than once.
      
      This patch addresses the first issue by enabling logging of all
      references to user-defined variables in triggers/stored functions
      and not only references from table-updating statements.
      
      The second issue stemmed from the fact that for user-defined
      variables used from triggers or stored functions called from
      table-updating statements we were writing binlog events for each
      reference instead of only one event for the first reference.
      This problem is already solved for stored functions called from
      non-updating statements with help of "event unioning" mechanism.
      So the patch simply extends this mechanism to the case affected.
      It also fixes small problem in this mechanism which caused wrong
      logging of references to user-variables in cases when non-updating
      statement called several stored functions which used the same
      variable and some of these function calls were omitted from binlog
      as they were not updating any tables.
      4c6ced9f
  6. 26 Jan, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #24653. · 36df33d8
      igor@olga.mysql.com authored
      The bug report has demonstrated the following two problems.
      1. If an ORDER/GROUP BY list includes a constant expression being 
      optimized away and, at the same time, containing single-row
      subselects that return more that one row, no error is reported.
      Strictly speaking the standard allows to ignore error in this case.
      Yet, now a corresponding fatal error is reported in this case.
      2. If a query requires sorting by expressions containing single-row
      subselects that, however, return more than one row, then the execution
      of the query may cause a server crash. 
      To fix this some code has been added that blocks execution of a subselect
      item in case of a fatal error in the method Item_subselect::exec.
      36df33d8
  7. 22 Jan, 2007 1 commit
  8. 18 Jan, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #25382: Passing NULL to an UDF called from stored procedures · 20d94f11
      gkodinov/kgeorge@macbook.gmz authored
       crashes server
       Check for null value is reliable only after calling some of the 
       val_xxx() methods. If the val_xxx() method is not called
       the null_value flag will be set only for certain types of NULL
       values (like SQL constant NULLs for example).
       This caused a crash while trying to dereference a NULL pointer
       that is returned by val_str() for NULL values.
       Fixed by swapping the order of val_xxx() and null_value check.
      20d94f11
  9. 09 Jan, 2007 2 commits
    • evgen@moonbone.local's avatar
      Fixed bug#16861: User defined variable can have a wrong value if a tmp table was · e098f736
      evgen@moonbone.local authored
      used.
      
      The Item::save_in_field() function is called from fill_record() to fill the 
      new row with data while execution of the CREATE TABLE ... SELECT statement.
      Item::save_in_field() calls val_xxx() methods in order to get values.
      val_xxx() methods do not take into account the result field. Due to this
      Item_func_set_user_var::val_xxx() methods returns values from the original
      table, not from the temporary one.
      
      The save_in_field() member function is added to the Item_func_set_user_var
      class. It detects whether the result field should be used and properly updates
      the value of the user variable.
      e098f736
    • kroki/tomash@moonlight.home's avatar
      BUG#23443: user-defined variables can consume too much memory in the · 5b4d9d87
      kroki/tomash@moonlight.home authored
                 server
      
      The problem was that when memory was exhausted HEAP engine could crash
      (GROUP BY uses HEAP TABLE).  Alternatively, if SET was used, it could
      report an error "You may only use constant expressions with SET" instead
      of "Out of memory (Needed NNNNNN bytes)".
      
      The solution is:
       - pass MY_WME to (some) calls to my_malloc() to get correct message.
       - fix heap_write() so that the first key is skipped during cleanup
         on ENOMEM because it wasn't inserted and doesn't have to be
         deleted.
      
      No test case is provided because we can't test out-of-memory behaviour
      in our current test framework.
      5b4d9d87
  10. 23 Dec, 2006 1 commit
  11. 14 Dec, 2006 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings detected by option -Wshadow and -Wunused: · 88dd873d
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables and functions
      - Added #ifdef around code that is not used
      - Renamed variables and functions to avoid conflicts
      - Removed some not used arguments
      
      Fixed some class/struct warnings in ndb
      Added define IS_LONGDATA() to simplify code in libmysql.c
      
      I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
      88dd873d
  12. 04 Dec, 2006 1 commit
  13. 30 Nov, 2006 1 commit
  14. 15 Nov, 2006 1 commit
  15. 13 Nov, 2006 3 commits
    • cmiller@zippy.cornsilk.net's avatar
      Bug#18761: constant expression as UDF parameters not passed in as constant · 8471897f
      cmiller@zippy.cornsilk.net authored
      The code that set up data to be passed to user-defined functions was very
      old and analyzed the "Type" of the data that was passed into the UDF, when
      it really should analyze the "return_type", which is hard-coded for simple
      Items and works correctly for complex ones like functions.
      ---
      Added test at Sergei's behest.
      8471897f
    • dlenev@mockturtle.local's avatar
      Fix for bug bug#23651 "Server crashes when trigger which uses · dd1a4f57
      dlenev@mockturtle.local authored
      stored function invoked from different connections".
      
      Invocation of trigger which was using stored function from different
      connections caused server crashes (for non-debug server this happened
      in highly concurrent environment, but debug server failed on assertion
      in relatively simple scenario).
      
      Item_func_sp was not safe to use in triggers (in other words for
      re-execution from different threads) as artificial TABLE object
      pointed by Item_func_sp::dummy_table referenced incorrect THD
      object. To fix the problem we force re-initialization of this
      object for each re-execution of statement.
      dd1a4f57
    • holyfoot/hf@mysql.com/deer.(none)'s avatar
      6e0045ed
  16. 08 Nov, 2006 1 commit
    • cmiller@zippy.cornsilk.net's avatar
      Bug#10963: LEFT/RIGHT/SUBSTR/.. string functions returns wrong result \ · 6260e12b
      cmiller@zippy.cornsilk.net authored
        on large length
        
      Problem:  Most (all) of the numeric inputs were being coerced into
      int (32 bit) sized variables.  Works OK for sane inputs; any input
      larger than 2^32 (or 2^31 for signed vars) exihibited predictable
      wrapping behavior (up to about 10^18) and then started having really
      strange behaviour past that point (since the conversion to 64 bit int
      from the DECIMAL type can do weird things on out of range numbers).
      
      Solution: 1)  Add many tests.  2)  Convert input from (u)long type to
      (u)longlong.  3)  Do (sometimes multiple) sanity checks on input,
      keeping in mind that sometimes a negative longlong is not a negative
      longlong (if the unsigned_flag is set).  4) Emulate existing behavior
      w/rt negative and "small" out-of-bounds values.
      6260e12b
  17. 06 Nov, 2006 1 commit
  18. 30 Oct, 2006 1 commit
  19. 24 Oct, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #21809: Error 1356 while selecting from view with grouping though underlying · 932d86bb
      gkodinov/kgeorge@macbook.gmz authored
                  select OK.
      The SQL parser was using Item::name to transfer user defined function attributes
      to the user defined function (udf). It was not distinguishing between user defined 
      function call arguments and stored procedure call arguments. Setting Item::name 
      was causing Item_ref::print() method to print the argument as quoted identifiers 
      and caused views that reference aggregate functions as udf call arguments (and 
      rely on Item::print() for the text of the view to store) to throw an undefined 
      identifier error.
      Overloaded Item_ref::print to print aggregate functions as such when printing
      the references to aggregate functions taken out of context by split_sum_func2()
      Fixed the parser to properly detect using AS clause in stored procedure arguments
      as an error.
      Fixed printing the arguments of udf call to print properly the udf attribute.
      932d86bb
  20. 06 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID. · ee0cebf9
      kroki/tomash@moonlight.intranet authored
      Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored
      procedures.  However, 4.1 had some bugs that were fixed in 5.0 by the
      patch for bug#21726, and this patch is a backport of those fixes.
      Namely, in 4.1 it fixes:
      
        - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific).
      
        - LAST_INSERT_ID() could return the value generated by current
          statement if the call happens after the generation, like in
      
            CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT);
            INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID());
      
        - Redundant binary log LAST_INSERT_ID_EVENTs could be generated.
      ee0cebf9
  21. 03 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      Fix for the patch for bug#21726: Incorrect result with multiple · 8798b462
      kroki/tomash@moonlight.intranet authored
      invocations of LAST_INSERT_ID.
      
      Reding of LAST_INSERT_ID inside stored function wasn't noted by caller,
      and no LAST_INSERT_ID_EVENT was issued for binary log.
      
      The solution is to add THD::last_insert_id_used_bin_log, which is much
      like THD::last_insert_id_used, but is reset only for upper-level
      statements.  This new variable is used to issue LAST_INSERT_ID_EVENT.
      8798b462
  22. 02 Oct, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      BUG#21726: Incorrect result with multiple invocations of LAST_INSERT_ID · 5ea8adfa
      kroki/tomash@moonlight.intranet authored
      Non-upper-level INSERTs (the ones in the body of stored procedure,
      stored function, or trigger) into a table that have AUTO_INCREMENT
      column didn't affected the result of LAST_INSERT_ID() on this level.
      
      The problem was introduced with the fix of bug 6880, which in turn was
      introduced with the fix of bug 3117, where current insert_id value was
      remembered on the first call to LAST_INSERT_ID() (bug 3117) and was
      returned from that function until it was reset before the next
      _upper-level_ statement (bug 6880).
      
      The fix for bug#21726 brings back the behaviour of version 4.0, and
      implements the following: remember insert_id value at the beginning
      of the statement or expression (which at that point equals to
      the first insert_id value generated by the previous statement), and
      return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID.
      
      Thus, the value returned by LAST_INSERT_ID() is not affected by values
      generated by current statement, nor by LAST_INSERT_ID(expr) calls in
      this statement.
      
      Version 5.1 does not have this bug (it was fixed by WL 3146).
      5ea8adfa
  23. 13 Sep, 2006 2 commits
  24. 12 Sep, 2006 2 commits
  25. 09 Sep, 2006 1 commit
  26. 08 Sep, 2006 1 commit
  27. 07 Sep, 2006 1 commit
  28. 24 Aug, 2006 1 commit
  29. 22 Aug, 2006 2 commits
    • evgen@moonbone.local's avatar
      item_cmpfunc.cc, item.cc: · 44cad14b
      evgen@moonbone.local authored
        Additional fix for bug #21475
      item_func.h, item_func.cc:
        Additional fix for bug#16861
      44cad14b
    • evgen@sunlight.local's avatar
      Fixed bug#16861: User defined variable can have a wrong value if a tmp table was · f17a536e
      evgen@sunlight.local authored
      used.
      
      Sorting by RAND() uses a temporary table in order to get a correct results.
      User defined variable was set during filling the temporary table and later
      on it is substituted for its value from the temporary table. Due to this
      it contains the last value stored in the temporary table.
      
      Now if the result_field is set for the Item_func_set_user_var object it 
      updates variable from the result_field value when being sent to a client.
      
      The Item_func_set_user_var::check() now accepts a use_result_field
      parameter. Depending on its value the result_field or the args[0] is used
      to get current value.
      f17a536e
  30. 26 Jul, 2006 1 commit
  31. 25 Jul, 2006 1 commit
    • evgen@moonbone.local's avatar
      Fixed bug#19862: Sort with filesort by function evaluates function twice · 4ee2e07c
      evgen@moonbone.local authored
      When there is no index defined filesort is used to sort the result of a
      query. If there is a function in the select list and the result set should be
      ordered by it's value then this function will be evaluated twice. First time to
      get the value of the sort key and second time to send its value to a user.
      This happens because filesort when sorts a table remembers only values of its
      fields but not values of functions.
      All functions are affected. But taking into account that SP and UDF functions
      can be both expensive and non-deterministic a temporary table should be used 
      to store their results and then sort it to avoid twice SP evaluation and to 
      get a correct result.
      
      If an expression referenced in an ORDER clause contains a SP or UDF 
      function, force the use of a temporary table.
      
      A new Item_processor function called func_type_checker_processor is added
      to check whether the expression contains a function of a particular type.
      4ee2e07c
  32. 13 Jul, 2006 1 commit
    • kroki/tomash@moonlight.intranet's avatar
      Bug#18630: Arguments of suid routine calculated in wrong security · 4272d1ef
      kroki/tomash@moonlight.intranet authored
                 context.
      
      Routine arguments were evaluated in the security context of the routine
      itself, not in the caller's context.
      
      The bug is fixed the following way:
      
        - Item_func_sp::find_and_check_access() has been split into two
          functions: Item_func_sp::find_and_check_access() itself only
          finds the function and check that the caller have EXECUTE privilege
          on it.  New function set_routine_security_ctx() changes security
          context for SUID routines and checks that definer have EXECUTE
          privilege too.
      
        - new function sp_head::execute_trigger() is called from
          Table_triggers_list::process_triggers() instead of
          sp_head::execute_function(), and is effectively just as the
          sp_head::execute_function() is, with all non-trigger related code
          removed, and added trigger-specific security context switch.
      
        - call to Item_func_sp::find_and_check_access() stays outside
          of sp_head::execute_function(), and there is a code in
          sql_parse.cc before the call to sp_head::execute_procedure() that
          checks that the caller have EXECUTE privilege, but both
          sp_head::execute_function() and sp_head::execute_procedure() call
          set_routine_security_ctx() after evaluating their parameters,
          and restore the context after the body is executed.
      4272d1ef
  33. 09 Jul, 2006 1 commit
  34. 30 Jun, 2006 1 commit
    • knielsen@mysql.com's avatar
      BUG#20769: Dangling pointer in ctype_recoding test case. · 1d56a972
      knielsen@mysql.com authored
      In some functions dealing with strings and character sets, the wrong
      pointers were saved for restoration in THD::rollback_item_tree_changes().
      This could potentially cause random corruption or crashes.
      
      Fixed by passing the original Item ** locations, not local stack copies.
      
      Also remove unnecessary use of default arguments.
      1d56a972