An error occurred fetching the project authors.
  1. 30 Jul, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug#37662 nested if() inside sum() is parsed in exponential time · 425abb49
      Georgi Kodinov authored
            
      min() and max() functions are implemented in MySQL as macros.
      This means that max(a,b) is expanded to: ((a) > (b) ? (a) : (b))
      Note how 'a' is quoted two times.
      Now imagine 'a' is a recursive function call that's several 10s of levels deep.
      And the recursive function does max() with a function arg as well to dive into
      recursion.
      This means that simple function call can take most of the clock time.
      Identified and fixed several such calls to max()/min() : including the IF() 
      sql function implementation.
      425abb49
  2. 15 Jul, 2008 1 commit
  3. 14 Jul, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #37761: IN handles NULL differently for table-subquery · 211164ff
      Gleb Shchepa authored
                  and value-list
      
      The server returns unexpected results if a right side of the 
      NOT IN clause consists of NULL value and some constants of
      the same type, for example:
      
        SELECT * FROM t WHERE NOT t.id IN (NULL, 1, 2) 
        
      may return 3, 4, 5 etc if a table contains these values.
      
      
      The Item_func_in::val_int method has been modified:
      unnecessary resets of an Item_func_case::has_null field 
      value has been moved outside of an argument comparison
      loop. (Also unnecessary re-initialization of the null_value
      field has been moved).
      211164ff
  4. 28 Mar, 2008 1 commit
  5. 22 Feb, 2008 1 commit
    • anozdrin/alik@quad.'s avatar
      Fix for Bug#30217: Views: changes in metadata behaviour · 340906f4
      anozdrin/alik@quad. authored
      between 5.0 and 5.1.
        
      The problem was that in the patch for Bug#11986 it was decided
      to store original query in UTF8 encoding for the INFORMATION_SCHEMA.
      This approach however turned out to be quite difficult to implement
      properly. The main problem is to preserve the same IS-output after
      dump/restore.
        
      So, the fix is to rollback to the previous functionality, but also
      to fix it to support multi-character-set-queries properly. The idea
      is to generate INFORMATION_SCHEMA-query from the item-tree after
      parsing view declaration. The IS-query should:
        - be completely in UTF8;
        - not contain character set introducers.
        
      For more information, see WL4052.
      340906f4
  6. 13 Feb, 2008 1 commit
  7. 30 Jan, 2008 2 commits
  8. 09 Dec, 2007 1 commit
  9. 08 Dec, 2007 1 commit
    • timour/tkatchaounov@lapi.mysql.com's avatar
      Fix for BUG#32694 "NOT NULL table field in a subquery produces invalid results" · 9be915e7
      timour/tkatchaounov@lapi.mysql.com authored
        
      The problem was that when convert_constant_item is called for subqueries,
      this happens when we already started executing the top-level query, and
      the field argument of convert_constant_item pointed to a valid table row.
      In turn convert_constant_item used the field buffer to compute the value
      of its item argument. This copied the item's value into the field,
      and made equalities with outer references always true.
        
      The fix saves/restores the original field's value when it belongs to an
      outer table.
      9be915e7
  10. 23 Nov, 2007 1 commit
  11. 21 Nov, 2007 1 commit
  12. 17 Nov, 2007 1 commit
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #32335. · f93b5a9c
      gshchepa/uchum@gleb.loc authored
      Comparison of a BIGINT NOT NULL column with a constant arithmetic
      expression that evaluates to NULL caused error 1048: "Column '...'
      cannot be null".
      
      Made convert_constant_item() check if the constant expression is NULL
      before attempting to store it in a field. Attempts to store NULL in a
      NOT NULL field caused query errors.
      f93b5a9c
  13. 10 Nov, 2007 2 commits
    • gshchepa/uchum@gleb.loc's avatar
      Fixed bug #28076: inconsistent binary/varbinary comparison. · 0aabb89e
      gshchepa/uchum@gleb.loc authored
      After adding an index the <VARBINARY> IN (SELECT <BINARY> ...)
      clause returned a wrong result: the VARBINARY value was illegally padded
      with zero bytes to the length of the BINARY column for the index search.
      (<VARBINARY>, ...) IN (SELECT <BINARY>, ... ) clauses are affected too.
      0aabb89e
    • tnurnberg@mysql.com/white.intern.koehntopp.de's avatar
      Bug#31800: Date comparison fails with timezone and slashes for greater than comparison · dd7452c2
      BETWEEN was more lenient with regard to what it accepted as a DATE/DATETIME
      in comparisons than greater-than and less-than were. ChangeSet makes < >
      comparisons similarly robust with regard to trailing garbage (" GMT-1")
      and "missing" leading zeros. Now all three comparators behave similarly
      in that they throw a warning for "junk" at the end of the data, but then
      proceed anyway if possible. Before < > fell back on a string- (rather than
      date-) comparison when a warning-condition was raised in the string-to-date
      conversion. Now the fallback only happens on actual errors, while warning-
      conditions still result in a warning being to delivered to the client.
      dd7452c2
  14. 29 Oct, 2007 1 commit
  15. 24 Oct, 2007 1 commit
  16. 17 Oct, 2007 1 commit
    • kaa@polly.(none)'s avatar
      Fix for bug #31207: Test "join_nested" shows different strategy on IA64 · 6d1f3e8d
      kaa@polly.(none) authored
      CPUs / Intel's ICC compile
      
      The bug is a combination of two problems:
      
      1. IA64/ICC MySQL binaries use glibc's qsort(), not the one in mysys.
      
      2. The order relation implemented by join_tab_cmp() is not transitive,
      i.e. it is possible to choose such a, b and c that (a < b) && (b < c)
      but (c < a). This implies that result of a sort using the relation
      implemented by join_tab_cmp() depends on the order in which
      elements are compared, i.e. the result is implementation-specific. Since
      choose_plan() uses qsort() to pre-sort the
      join tables using join_tab_cmp() as a compare function, the results of
      the sorting may vary depending on qsort() implementation.
      
      It is neither possible nor important to implement a better ordering
      algorithm in join_tab_cmp(). Therefore the only way to fix it is to
      force our own qsort() to be used by renaming it to my_qsort(), so we don't depend
      on linker to decide that.
      
      This patch also "fixes" bug #20530: qsort redefinition violates the
      standard.
      6d1f3e8d
  17. 11 Oct, 2007 2 commits
  18. 10 Oct, 2007 1 commit
  19. 05 Oct, 2007 1 commit
  20. 22 Sep, 2007 1 commit
    • evgen@sunlight.local's avatar
      Bug#27216: functions with parameters of different date types may return wrong · 36bf417b
      evgen@sunlight.local authored
      type of the result.
      
      There are several functions that accept parameters of different types.
      The result field type of such functions was determined based on
      the aggregated result type of its arguments. As the DATE and the DATETIME
      types are represented by the STRING type, the result field type
      of the affected functions was always STRING for DATE/DATETIME arguments.
      The affected functions are COALESCE, IF, IFNULL, CASE, LEAST/GREATEST, CASE.
      
      Now the affected functions aggregate the field types of their arguments rather
      than their result types and return the result of aggregation as their result
      field type.
      The cached_field_type member variable is added to the number of classes to
      hold the aggregated result field type.
      The str_to_date() function's result field type now defaults to the
      MYSQL_TYPE_DATETIME.
      The agg_field_type() function is added. It aggregates field types with help
      of the Field::field_type_merge() function.
      The create_table_from_items() function now uses the 
      item->tmp_table_field_from_field_type() function to get the proper field
      when the item is a function with a STRING result type.
      36bf417b
  21. 13 Aug, 2007 1 commit
    • monty@mysql.com/nosik.monty.fi's avatar
      Fixed a lot of compiler warnings and errors detected by Forte C++ on Solaris · e53a73e2
      monty@mysql.com/nosik.monty.fi authored
      Faster thr_alarm()
      Added 'Opened_files' status variable to track calls to my_open()
      Don't give warnings when running mysql_install_db
      Added option --source-install to mysql_install_db
      
      I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
      index_read()      -> index_read_map()
      index_read_idx()  -> index_read_idx_map()
      index_read_last() -> index_read_last_map()
      e53a73e2
  22. 15 Jul, 2007 4 commits
    • evgen@moonbone.local's avatar
      item_cmpfunc.cc: · 17654758
      evgen@moonbone.local authored
        A typo fixed.
      17654758
    • evgen@moonbone.local's avatar
      item_cmpfunc.cc: · 49db78b3
      evgen@moonbone.local authored
        Fixed compiler warning.
      49db78b3
    • evgen@moonbone.local's avatar
      item_cmpfunc.cc: · 9dc929f2
      evgen@moonbone.local authored
        A comment changed.
      9dc929f2
    • evgen@moonbone.local's avatar
      Extended fix for the bug#29555. · 975d2232
      evgen@moonbone.local authored
      The get_time_value function is added. It is used to obtain TIME values both
      from items the can return time as an integer and from items that can return
      time only as a string.
      The Arg_comparator::compare_datetime function now uses pointer to a getter
      function to obtain values to compare. Now this function is also used for
      comparison of TIME values.
      The get_value_func variable is added to the Arg_comparator class.
      It points to a getter function for the DATE/DATETIME/TIME comparator.
      975d2232
  23. 12 Jul, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#29739: Incorrect time comparison in BETWEEN. · 1b1464ba
      evgen@moonbone.local authored
      Time values were compared by the BETWEEN function as strings. This led to a
      wrong result in cases when some of arguments are less than 100 hours and other
      are greater.
      
      Now if all 3 arguments of the BETWEEN function are of the TIME type then
      they are compared as integers.
      1b1464ba
  24. 11 Jul, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#29555: Comparing time values as strings may lead to a wrong result. · df9c376e
      evgen@moonbone.local authored
      Time values were compared as strings. This led to a wrong comparison
      result when comparing values one of which is under 100 hours and another is
      over 100 hours.
      
      Now when the Arg_comparator::set_cmp_func function sees that both items to
      compare are of the TIME type it sets the comparator to the
      Arg_comparator::compare_e_int or the Arg_comparator::compare_int_unsigned
      functions.
      df9c376e
  25. 11 Jun, 2007 1 commit
  26. 05 Jun, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28778: Wrong result of BETWEEN when comparing a DATETIME field with an · 0a91c7cc
      evgen@moonbone.local authored
      integer constants.
      
      This bug is introduced by the fix for bug#16377. Before the fix the 
      Item_func_between::fix_length_and_dec method converted the second and third
      arguments to the type of the first argument if they were constant and the first
      argument is of the DATE/DATETIME type. That approach worked well for integer
      constants and sometimes produced bad result for string constants. The fix for
      the bug#16377 wrongly removed that code at all and as a result of this the
      comparison of a DATETIME field and an integer constant was carried out in a
      wrong way and sometimes led to wrong result sets.
      
      Now the Item_func_between::fix_length_and_dec method converts the second and
      third arguments to the type of the first argument if they are constant, the
      first argument is of the DATE/DATETIME type and the DATETIME comparator isn't
      applicable.
      0a91c7cc
  27. 30 May, 2007 1 commit
  28. 29 May, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28450: The Item_date_add_interval in select list may fail the field · 268fdf5d
      evgen@moonbone.local authored
      type assertion.
      
      The bug was introduced by the patch for bug #16377.
      The "+ INTERVAL" (Item_date_add_interval) function detects its result type
      by the type of its first argument. But in some cases it returns STRING
      as the result type. This happens when, for example, the first argument is a 
      DATE represented as string. All this makes the get_datetime_value()
      function misinterpret such result and return wrong DATE/DATETIME value.
      To avoid such cases in the fix for #16377 the code that detects correct result
      field type on the first execution was added to the
      Item_date_add_interval::get_date() function. Due to this the result
      field type of the Item_date_add_interval item stored by the send_fields()
      function differs from item's result field type at the moment when
      the item is actually sent. It causes an assertion failure.
      
      Now the get_datetime_value() detects that the DATE value is returned by
      some item not only by checking the result field type but also by comparing
      the returned value with the 100000000L constant - any DATE value should be
      less than this value.
      Removed result field type adjusting code from the
      Item_date_add_interval::get_date() function.
      268fdf5d
  29. 28 May, 2007 1 commit
  30. 24 May, 2007 1 commit
  31. 17 May, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28261: Wrong DATETIME comparison result when the GET_USER_VAR function · 0e3c4f67
      evgen@moonbone.local authored
      is involved.
      
      The Arg_comparator::compare_datetime() comparator caches its arguments if
      they are constants i.e. const_item() returns true. The
      Item_func_get_user_var::const_item() returns true or false based on
      the current query_id and the query_id where the variable was created.
      Thus even if a query can change its value its const_item() still will return
      true. All this leads to a wrong comparison result when an object of the
      Item_func_get_user_var class is involved.
      
      Now the Arg_comparator::can_compare_as_dates() and the
      get_datetime_value() functions never cache result of the GET_USER_VAR()
      function (the Item_func_get_user_var class).
      0e3c4f67
  32. 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
  33. 15 May, 2007 1 commit
    • evgen@moonbone.local's avatar
      Bug#28208: Wrong result of a non-const STRING function with a const DATETIME · fbb23326
      evgen@moonbone.local authored
      function.
      
      A wrong  condition was used to check that the
      Arg_comparator::can_compare_as_dates() function calculated the value of the
      string constant. When comparing a non-const STRING function with a constant
      DATETIME function it leads to saving an arbitrary value as a cached value of
      the DATETIME function.
      
      Now the Arg_comparator::set_cmp_func() function initializes the const_value
      variable to the impossible DATETIME value (-1) and this const_value is
      cached only if it was changed by the Arg_comparator::can_compare_as_dates()
      function.
      fbb23326
  34. 14 May, 2007 1 commit
    • 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