An error occurred fetching the project authors.
  1. 23 Jan, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #6172: RAND(a) should only accept constant values as arguments · 450e9b6b
      gkodinov/kgeorge@macbook.gmz authored
       RAND() must accept scalar expressions regardless of their kind.
       That includes both constant expressions and expressions that 
       depend on column values.
       When the expression is constant the random seed can be initialized
       at compile time.
       However when the expression is not constant the random seed must be
       initialized at each invocation (while it still can be allocated at
       compile time).
       Implemented the above rules by extending Item_func_rand::val_real()
       to initialize the random seed at the correct place.
      450e9b6b
  2. 09 Jan, 2007 1 commit
    • 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
  3. 23 Dec, 2006 1 commit
  4. 04 Dec, 2006 1 commit
  5. 02 Dec, 2006 1 commit
  6. 30 Nov, 2006 2 commits
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed portability issue in my_thr_init.c (was added in my last push) · 3d409560
      monty@mysql.com/narttu.mysql.fi authored
      Fixed compiler warnings (detected by VC++):
      - Removed not used variables
      - Added casts
      - Fixed wrong assignments to bool
      - Fixed wrong calls with bool arguments
      - Added missing argument to store(longlong), which caused wrong store method to be called.
      3d409560
    • monty@mysql.com/narttu.mysql.fi's avatar
      Fixed compiler warnings (Mostly VC++): · 3a35c300
      monty@mysql.com/narttu.mysql.fi authored
      - Removed not used variables
      - Changed some ulong parameters/variables to ulonglong (possible serious bug)
      - Added casts to get rid of safe assignment from longlong to long (and similar)
      - Added casts to function parameters
      - Fixed signed/unsigned compares
      - Added some constructores to structures
      - Removed some not portable constructs
      
      Better fix for bug Bug #21428 "skipped 9 bytes from file: socket (3)" on "mysqladmin shutdown"
      (Added new parameter to net_clear() to define when we want the communication buffer to be emptied)
      3a35c300
  7. 26 Nov, 2006 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a LOT of compiler warnings · fa81a82e
      monty@mysql.com/nosik.monty.fi authored
      Added missing DBUG_RETURN statements (in mysqldump.c)
      Added missing enums
      Fixed a lot of wrong DBUG_PRINT() statements, some of which could cause crashes
      Removed usage of %lld and %p in printf strings as these are not portable or produces different results on different systems.
      fa81a82e
  8. 17 Nov, 2006 1 commit
  9. 16 Nov, 2006 1 commit
    • malff/marcsql@weblab.(none)'s avatar
      Bug#22684 (BENCHMARK, ENCODE, DECODE and FORMAT are not real functions) · ccfbd686
      malff/marcsql@weblab.(none) authored
      Before this change, the functions BENCHMARK, ENCODE, DECODE and FORMAT could
      only accept a constant for some parameters.
      
      After this change, this restriction has been removed. An implication is that
      these functions can also be used in prepared statements.
      
      The change consist of changing the following classes:
      - Item_func_benchmark
      - Item_func_encode
      - Item_func_decode
      - Item_func_format
      to:
      - only accept Item* in the constructor,
      - and evaluate arguments during calls to val_xxx()
      which fits the general design of all the other functions.
      
      The 'TODO' items identified in item_create.cc during the work done for
      Bug 21114 are addressed by this fix, as a natural consequence of aligning
      the design.
      
      In the 'func_str' test, a single very long test line involving an explain
      extended select with many functions has been rewritten into multiple
      separate tests, to improve maintainability.
      The result of explain extended select decode(encode(...)) has changed,
      since the encode and decode functions now print all their parameters.
      ccfbd686
  10. 15 Nov, 2006 2 commits
    • cmiller@zippy.cornsilk.net's avatar
      Bug#19955: unsigned bigint used as signed with MOD function · 5d4c57b9
      cmiller@zippy.cornsilk.net authored
      Problem:  When we have a really large number (between 2^63 and 2^64)
      as the left side of the mod operator, it gets improperly corerced
      into a signed value.
      
      Solution:  Added check to see if the "negative" number is really
      positive, and if so, cast it.
      5d4c57b9
    • tnurnberg@salvation.intern.azundris.com's avatar
      Bug#16456 "RBR: rpl_sp.test expects query to fail, but passes in RBR" · ea3bf1b2
      calling (rather than defining) non-deterministic SP in SBR (as opposed
      to RBR or mixed) will throw an error now.
      
      require mixed mode for tests now. SBR will now fail when calling
      non-deter SPs and SFs (as it should), and RBR already failed by virtue of
      giving different results for "show binlog" than the results-file has.
      also test for 16456 now. lastly make amends because one of the tests
      fails with a new error # now as code was added to sql_trigger.cc while
      test was disabled.
      ea3bf1b2
  11. 13 Nov, 2006 4 commits
  12. 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
  13. 06 Nov, 2006 1 commit
  14. 30 Oct, 2006 1 commit
  15. 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
  16. 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
  17. 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
  18. 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
  19. 13 Sep, 2006 3 commits
  20. 12 Sep, 2006 2 commits
  21. 09 Sep, 2006 1 commit
  22. 08 Sep, 2006 1 commit
  23. 07 Sep, 2006 1 commit
  24. 24 Aug, 2006 1 commit
  25. 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
  26. 08 Aug, 2006 1 commit
  27. 26 Jul, 2006 1 commit
  28. 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
  29. 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
  30. 09 Jul, 2006 2 commits
    • guilhem@gbichot3.local's avatar
      WL#3146 "less locking in auto_increment": · 0594e1b8
      guilhem@gbichot3.local authored
      this is a cleanup patch for our current auto_increment handling:
      new names for auto_increment variables in THD, new methods to manipulate them
      (see sql_class.h), some move into handler::, causing less backup/restore
      work when executing substatements. 
      This makes the logic hopefully clearer, less work is is needed in
      mysql_insert().
      By cleaning up, using different variables for different purposes (instead
      of one for 3 things...), we fix those bugs, which someone may want to fix
      in 5.0 too:
      BUG#20339 "stored procedure using LAST_INSERT_ID() does not replicate
      statement-based"
      BUG#20341 "stored function inserting into one auto_increment puts bad
      data in slave"
      BUG#19243 "wrong LAST_INSERT_ID() after ON DUPLICATE KEY UPDATE"
      (now if a row is updated, LAST_INSERT_ID() will return its id)
      and re-fixes:
      BUG#6880 "LAST_INSERT_ID() value changes during multi-row INSERT"
      (already fixed differently by Ramil in 4.1)
      Test of documented behaviour of mysql_insert_id() (there was no test).
      The behaviour changes introduced are:
      - LAST_INSERT_ID() now returns "the first autogenerated auto_increment value
      successfully inserted", instead of "the first autogenerated auto_increment
      value if any row was successfully inserted", see auto_increment.test.
      Same for mysql_insert_id(), see mysql_client_test.c.
      - LAST_INSERT_ID() returns the id of the updated row if ON DUPLICATE KEY
      UPDATE, see auto_increment.test. Same for mysql_insert_id(), see
      mysql_client_test.c.
      - LAST_INSERT_ID() does not change if no autogenerated value was successfully 
      inserted (it used to then be 0), see auto_increment.test.
      - if in INSERT SELECT no autogenerated value was successfully inserted,
      mysql_insert_id() now returns the id of the last inserted row (it already
      did this for INSERT VALUES), see mysql_client_test.c.
      - if INSERT SELECT uses LAST_INSERT_ID(X), mysql_insert_id() now returns X
      (it already did this for INSERT VALUES), see mysql_client_test.c.
      - NDB now behaves like other engines wrt SET INSERT_ID: with INSERT IGNORE,
      the id passed in SET INSERT_ID is re-used until a row succeeds; SET INSERT_ID
      influences not only the first row now.
      
      Additionally, when unlocking a table we check that the thread is not keeping
      a next_insert_id (as the table is unlocked that id is potentially out-of-date);
      forgetting about this next_insert_id is done in a new
      handler::ha_release_auto_increment().
      
      Finally we prepare for engines capable of reserving finite-length intervals
      of auto_increment values: we store such intervals in THD. The next step
      (to be done by the replication team in 5.1) is to read those intervals from
      THD and actually store them in the statement-based binary log. NDB
      will be a good engine to test that.
      0594e1b8
    • kostja@bodhi.local's avatar
      Fix compiler warnings in sql_udf.h: ISO C++ forbids casting · 2ab1e065
      kostja@bodhi.local authored
      between pointer to function and pointer to object.
      2ab1e065