An error occurred fetching the project authors.
  1. 24 May, 2007 1 commit
  2. 18 May, 2007 1 commit
    • thek@adventure.(none)'s avatar
      Bug#26277 User variable returns one type in SELECT @v and other for CREATE as SELECT @v · 637f85ca
      thek@adventure.(none) authored
      - Adding variable m_cached_result_type to keep the variable type consistent
        during the execution of a statement.
      - Before each result set is returned to the client the description of each
        column is sent as meta data.
        Previously the result type for a column could change if the hash variable
        entry changed between statements. This caused the result set of the query
        to alternate column types in certain cases which is not supported by MySQL
        client-server protocol. Example:
        Previously this sequence:
          SET @A:=1;
          SELECT @A:="text", @A;
        would return "text", "text";
       
        After the change the SELECT returns "text", 0
        The reson for this is that previously the result set from 'SELECT @A;'
        would always be of the type STRING, whereas now the type of the variable
        is taken from the last SET statement. However, 'SELECT @A:="text"' will
        return type of STRING since the right side of the assignment is used.
      637f85ca
  3. 16 May, 2007 1 commit
    • msvensson@pilot.blaudden's avatar
      Backport of TIME->MYSQL_TIME / Y2K fixset · a65d12a8
      msvensson@pilot.blaudden authored
         
      Made year 2000 handling more uniform
      Removed year 2000 handling out from calc_days()
      The above removes some bugs in date/datetimes with year between 0 and 200
      Now we get a note when we insert a datetime value into a date column
      For default values to CREATE, don't give errors for warning level NOTE
      Fixed some compiler failures
      Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
      Removed duplicate typedef TIME and replaced it with MYSQL_TIME
      
      Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
      Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
      Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
       
      a65d12a8
  4. 14 May, 2007 2 commits
    • tnurnberg@blasphemy.mysql.com's avatar
      Backport of TIME->MYSQL_TIME / Y2K fixset · 034aec5d
      tnurnberg@blasphemy.mysql.com authored
      Made year 2000 handling more uniform
      Removed year 2000 handling out from calc_days()
      The above removes some bugs in date/datetimes with year between 0 and 200
      Now we get a note when we insert a datetime value into a date column
      For default values to CREATE, don't give errors for warning level NOTE
      Fixed some compiler failures
      Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
      Removed duplicate typedef TIME and replaced it with MYSQL_TIME
      
      Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
      Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
      Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
      034aec5d
    • tnurnberg@blasphemy.mysql.com's avatar
      Backport of TIME->MYSQL_TIME / Y2K fixset · 30868bdc
      tnurnberg@blasphemy.mysql.com authored
      Made year 2000 handling more uniform
      Removed year 2000 handling out from calc_days()
      The above removes some bugs in date/datetimes with year between 0 and 200
      Now we get a note when we insert a datetime value into a date column
      For default values to CREATE, don't give errors for warning level NOTE
      Fixed some compiler failures
      Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
      Removed duplicate typedef TIME and replaced it with MYSQL_TIME
      
      Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
      Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
      Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
      30868bdc
  5. 09 May, 2007 1 commit
  6. 07 May, 2007 1 commit
  7. 04 May, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#27759: Wrong DATE/DATETIME comparison in LEAST()/GREATEST() functions. · 239f727b
      evgen@moonbone.local authored
      The LEAST/GREATEST functions compared DATE/DATETIME values as
      strings which in some cases could lead to a wrong result.
      
      A new member function called cmp_datetimes() is added to the
      Item_func_min_max class. It compares arguments in DATETIME context
      and returns index of the least/greatest argument.
      The Item_func_min_max::fix_length_and_dec() function now detects when
      arguments should be compared in DATETIME context and sets the newly
      added flag compare_as_dates. It indicates that the cmp_datetimes() function
      should be called to get a correct result.
      Item_func_min_max::val_xxx() methods are corrected to call the
      cmp_datetimes() function when needed.
      Objects of the Item_splocal class now stores and reports correct original
      field type.
      239f727b
  8. 30 Apr, 2007 1 commit
  9. 29 Apr, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #24856: the result set of a ROLLUP query with DISTINCT could lack · ce0be732
      igor@olga.mysql.com authored
      some rollup rows (rows with NULLs for grouping attributes) if GROUP BY
      list contained constant expressions.
      
      This happened because the results of constant expressions were not put
      in the temporary table used for duplicate elimination. In fact a constant
      item from the GROUP BY list of a ROLLUP query can be replaced for an
      Item_null_result object when a rollup row is produced . 
      
      Now the JOIN::rollup_init function wraps any constant item referenced in
      the GROYP BY list of a ROLLUP query into an Item_func object of a special
      class that is never detected as constant item. This ensures creation of
      fields for such  constant items in temporary tables and guarantees right
      results when the result of the rollup operation first has to be written
      into a temporary table, e.g. in the cases when duplicate elimination is
      required.  
      ce0be732
  10. 28 Apr, 2007 1 commit
    • kaa@polly.local's avatar
      Fix for bug #24912 "problems with bigint in abs() ceiling() round() truncate()... · 050c6723
      kaa@polly.local authored
      Fix for bug #24912 "problems with bigint in abs() ceiling() round() truncate() mod()" and a number of related problems:
      
      - unsigned flag was not handled correctly for a number of mathematical funcions, which led to incorrect results
      - passing large values as the number of decimals to ROUND() resulted in incorrect results and even server crashes in some cases
      - reverted the fix and the testcase for bug #10083 as it violates the manual
      - fixed some testcases which relied on broken ROUND() behavior
      050c6723
  11. 02 Apr, 2007 1 commit
  12. 23 Mar, 2007 1 commit
    • monty@mysql.com/narttu.mysql.fi's avatar
      Removed not used define YY_MAGIC_BELOW · 19336036
      monty@mysql.com/narttu.mysql.fi authored
      Made year 2000 handling more uniform
      Removed year 2000 handling out from calc_days()
      The above removes some bugs in date/datetimes with year between 0 and 200
      Now we get a note when we insert a datetime value into a date column
      For default values to CREATE, don't give errors for warning level NOTE
      Fixed some compiler failures
      Added library ws2_32 for windows compilation (needed if we want to compile with IOCP support)
      Removed duplicate typedef TIME and replaced it with MYSQL_TIME
      
      Better (more complete) fix for: Bug#21103 "DATE column not compared as DATE"
      Fixed properly Bug#18997 "DATE_ADD and DATE_SUB perform year2K autoconversion magic on 4-digit year value"
      Fixed Bug#23093 "Implicit conversion of 9912101 to date does not match cast(9912101 as date)"
      19336036
  13. 22 Mar, 2007 1 commit
  14. 16 Mar, 2007 1 commit
    • Kristofer.Pettersson@naruto.'s avatar
      Bug#20777 Function w BIGINT UNSIGNED shows diff. behaviour with and without --ps-protocol · 05bef788
      Kristofer.Pettersson@naruto. authored
      - Stored procedures returning unsinged values returns signed values if
        text protocol is used. The reason is that the stored proceedure item
        Item_func_sp wasn't initializing the member variables properly based
        on the information contained in the associated result field.
      - The patch is to upon field-item association, ::fix_fields, initialize
        the member variables in appropriate order.
      - Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR.
        This is changed to return the type of the actual result field.
      - Member function name sp_result_field was refactored to the more 
        appropriate init_result_field.
      - Member function name find_and_check_access was refactored to 
        sp_check_access.
      05bef788
  15. 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
  16. 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
  17. 31 Dec, 2006 1 commit
    • kent@mysql.com/kent-amd64.(none)'s avatar
      my_strtoll10-x86.s: · 6523aca7
      kent@mysql.com/kent-amd64.(none) authored
        Corrected spelling in copyright text
      Makefile.am:
        Don't update the files from BitKeeper
      Many files:
        Removed "MySQL Finland AB & TCX DataKonsult AB" from copyright header
        Adjusted year(s) in copyright header 
      Many files:
        Added GPL copyright text
      Removed files:
        Docs/Support/colspec-fix.pl
        Docs/Support/docbook-fixup.pl
        Docs/Support/docbook-prefix.pl
        Docs/Support/docbook-split
        Docs/Support/make-docbook
        Docs/Support/make-makefile
        Docs/Support/test-make-manual
        Docs/Support/test-make-manual-de
        Docs/Support/xwf
      6523aca7
  18. 23 Dec, 2006 1 commit
  19. 28 Nov, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      BUG#11927: Warnings shown for CAST( chr as signed) but not (chr + 0) · 42cd9567
      gkodinov/kgeorge@macbook.gmz authored
       When implicitly converting string fields to numbers the 
       string-to-number conversion error was not sent to the client.
       Added code to send the conversion error as warning.
       
       We also need to prevent generation of warnings from the places
       where val_xxx() methods are called for the sole purpose of updating
       the Item::null_value flag.
       To achieve that a special function is added (and called) : 
       update_null_value(). This function will set the no_errors flag and
       will call val_xxx(). The warning generation in Field_string::val_xxx()
       will use the flag when generating the conversion warnings. 
      42cd9567
  20. 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
  21. 07 Nov, 2006 1 commit
  22. 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
  23. 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
  24. 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
  25. 26 Sep, 2006 1 commit
  26. 25 Sep, 2006 1 commit
  27. 13 Sep, 2006 1 commit
  28. 12 Sep, 2006 1 commit
  29. 08 Sep, 2006 1 commit
  30. 07 Sep, 2006 1 commit
  31. 24 Aug, 2006 1 commit
  32. 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
  33. 26 Jul, 2006 1 commit
  34. 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
  35. 21 Jul, 2006 1 commit
  36. 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
  37. 01 Jul, 2006 1 commit
    • cmiller@zippy.(none)'s avatar
      Bug#19006: 4.0 valgrind problems (in test func_str) · 5039184e
      cmiller@zippy.(none) authored
      On exactly-sized Strings, the String::c_ptr() function peeked beyond the
      end of the buffer, possibly into unititialized space to see whether the 
      buffer was NUL-terminated.
      
      In a place that did peek improperly, we now use a c_ptr_safe() function, 
      which doesn't peek where it shouldn't.
      5039184e
  38. 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