An error occurred fetching the project authors.
  1. 07 Nov, 2007 1 commit
    • kaa@polly.(none)'s avatar
      Fix for bug #32103: optimizer crash when join on int and mediumint with · f1a3c364
      kaa@polly.(none) authored
      variable in where clause.
      
      Problem: the new_item() method of Item_uint used an incorrect
      constructor. "new Item_uint(name, max_length)" calls
      Item_uint::Item_uint(const char *str_arg, uint length) which assumes the
      first argument to be the string representation of the value, not the
      item's name. This could result in either a server crash or incorrect
      results depending on usage scenarios.
      
      Fixed by using the correct constructor in new_item():
      Item_uint::Item_uint(const char *str_arg, longlong i, uint length).
      f1a3c364
  2. 06 Dec, 2006 1 commit
  3. 26 Jul, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #21019: First result of SELECT COUNT(*) different than consecutive runs · 6766cfcd
      gkodinov/kgeorge@macbook.gmz authored
       When optimizing conditions like 'a = <some_val> OR a IS NULL' so that they're
       united into a single condition on the key and checked together the server must 
       check which value is the NULL value in a correct way : not only using ->is_null 
       but also check if the expression doesn't depend on any tables referenced in the 
       current statement. 
       This additional check must be performed because that optimization takes place 
       before the actual execution of the statement, so if the field was initialized 
       to NULL from a previous statement the optimization would be applied incorrectly.
      6766cfcd
  4. 25 Jul, 2006 1 commit
    • timour/timka@lamia.home's avatar
      Fix for BUG#20954: avg(keyval) retuns 0.38 but max(keyval) returns an empty set · 86ae2f3b
      timour/timka@lamia.home authored
      The problem was in that opt_sum_query() replaced MIN/MAX functions
      with the corresponding constant found in a key, but due to imprecise
      representation of float numbers, when evaluating the where clause,
      this comparison failed.
      
      When MIN/MAX optimization detects that all tables can be removed,
      also remove all conjuncts in a where clause that refer to these
      tables. As a result of this fix, these conditions are not evaluated
      twice, and in the case of float number comparisons we do not discard
      result rows due to imprecise float representation.
      
      As a side-effect this fix also corrects an unnoticed problem in
      bug 12882.
      86ae2f3b
  5. 20 Jun, 2006 1 commit
    • evgen@moonbone.local's avatar
      select.result: · ae6970e6
      evgen@moonbone.local authored
        Added test case for bug#18759 Incorrect string to numeric conversion.  
      select.test:
        Added test case for bug#18759 Incorrect string to numeric conversion.
      item_cmpfunc.cc:
        Cleanup after fix for bug#18360 removal
      ae6970e6
  6. 02 Jun, 2006 1 commit
  7. 30 May, 2006 1 commit
  8. 28 May, 2006 1 commit
  9. 24 Nov, 2005 1 commit
    • evgen@moonbone.local's avatar
      Fix bug #14482 Wrongly applied optimization in resolve_const_item() caused · a4a3215a
      evgen@moonbone.local authored
      crash
      
      resolve_const_item() substitutes item which will evaluate to constant with
      equvalent constant item, basing on the item's result type. In this case
      subselect was resolved as constant, and resolve_const_item() was substituting
      it's result's Item_caches to Item_null. Later Item_cache's function was called
      for Item_null object, which caused server crash.
      
      resolve_const_item() now substitutes constants for items with 
      result_type == ROW_RESULT only for Item_rows.
      a4a3215a
  10. 27 Oct, 2005 1 commit
  11. 13 Oct, 2005 3 commits
  12. 09 Oct, 2005 1 commit
    • evgen@moonbone.local's avatar
      Fix bug#7672 Unknown column error in order clause · 6bfc2d4b
      evgen@moonbone.local authored
      When fixing Item_func_plus in ORDER BY clause field c is searched in all
      opened tables, but because c is an alias it wasn't found there.
      
      This patch adds a flag to select_lex which allows Item_field::fix_fields() 
      to look up in select's item_list to find aliased fields.
      6bfc2d4b
  13. 07 Oct, 2005 1 commit
  14. 03 Oct, 2005 1 commit
  15. 27 Sep, 2005 1 commit
    • evgen@moonbone.local's avatar
      Fix bug#13356 resolve_const_item() wasn't able to handle Item_row items. · 4f4711bd
      evgen@moonbone.local authored
      resolve_const_item() assumed to be not called for Item_row items. For
      ensuring that DBUG_ASSERT(0) was set there.
      
      This patch adds section for Item_row items. If it can it recursively calls
      resolve_const_item() for each item the Item_row contains. If any of the
      contained items is null then whole Item_row substitued by Item_null. Otherwise
      it just returns.
      4f4711bd
  16. 19 Jul, 2005 1 commit
  17. 17 Jul, 2005 1 commit
    • igor@rurik.mysql.com's avatar
      select.result, select.test: · 54dd7e5e
      igor@rurik.mysql.com authored
        Added a test case for bug #11745.
      sql_select.cc:
        Fixed bug # 11745.
        Added support of where clause for queries with FROM DUAL.
      sql_yacc.yy:
        Fixed bug # 11745.
        Added optional where clause for queries with FROM DUAL.
      54dd7e5e
  18. 16 Jul, 2005 1 commit
    • timour@mysql.com's avatar
      Added test for Bug #11521 · ff0c7f22
      timour@mysql.com authored
      "Negative integer keys incorrectly substituted for 0 during range analysis."
      
      The problem is that the range optimizer incorrectly replaces any negative
      constant with '0' for all types except BIGINT because the method save_in_field()
      casts negative integers to non-negative. This causes incorrect query
      results where (0 = any_negative_number).
      
      The problem caused by this bug is fixed by the patch for BUG#11185.
      That patch constitutes an optimization due to which the problem code is
      never called with negative constants. This patch adds a test so we are sure
      that the problem does not reappear.
      ff0c7f22
  19. 15 Jul, 2005 1 commit
    • evgen@moonbone.local's avatar
      Fix bug#11482 4.1.12 produces different resultset for a complex query · 0298bc34
      evgen@moonbone.local authored
        than in previous 4.1.x
      
      Wrongly applied optimization were adding NOT NULL constraint which results in
      rejecting valid rows and reduced result set.
      
      The problem was that add_notnull_conds() while checking subquery were adding
      NOT NULL constraint to left joined table, to which, normally, optimization 
      don't have to be applied.
      0298bc34
  20. 14 Jul, 2005 1 commit
  21. 28 Jun, 2005 1 commit
    • bell@sanja.is.com.ua's avatar
      fixed not_null_tables() for IN() (BUG#9393) · 9283e3e3
      bell@sanja.is.com.ua authored
      (IN() remove NULL rows only for tables from first argument (value which we looking for in IN() list) but not for tables from IN() list)
      Also it will be better change Item::not_null_tables() to prohibit this optimisation by default for new created items in 5.0 or 5.1.
      9283e3e3
  22. 24 May, 2005 1 commit
  23. 19 May, 2005 1 commit
  24. 15 May, 2005 1 commit
    • sergefp@mysql.com's avatar
      Fix for BUG#10095: {wrong query results because of incorrect constant propagation} · f08287f3
      sergefp@mysql.com authored
      The problem: base_list::remove didn't modify base_list::last when removing 
      the last list element.
      The fix: If we remove the last element, find the element before it (by walking
      from the beginning of the list) and set base_list::last accordingly.
      
      The list gets corrupted in both 4.0 and 4.1. There are no visible problems in 
      current 4.1 because current 4.1 doesn't call where_cond->fix_fields() after 
      constant propagation step.
      f08287f3
  25. 13 May, 2005 1 commit
  26. 09 May, 2005 1 commit
  27. 31 Mar, 2005 1 commit
  28. 09 Mar, 2005 1 commit
    • timour@mysql.com's avatar
      Fix for BUG#7425. · f489e562
      timour@mysql.com authored
      The reported problems were due to two completely unrelated omissions.
      1) The file sort procedure didn't correctly create the sort key in
         make_sortkey when the sortkey was an unsigned integer.
      2) The name resolution procedure for column references inside a HAVING
         clause did not propagate the unsigned_flag of the resolved references.
      This patch corrects both problems.
      f489e562
  29. 17 Feb, 2005 1 commit
    • igor@rurik.mysql.com's avatar
      select.result, select.test: · eedde7ba
      igor@rurik.mysql.com authored
        Added a test case for bug #7098.
      sql_select.cc:
        Fixed bug #7098.
        When a string field was substituted for an equal constant
        the collation of the constant was changed by mistake for 
        the binary collation.
      eedde7ba
  30. 11 Feb, 2005 3 commits
    • igor@rurik.mysql.com's avatar
      select.result: · 634424ca
      igor@rurik.mysql.com authored
        After revision of the fix for bug #7520.
      table.cc:
        Revised the fix for bug #7520.
        Made it compliant with 5.0 code where the bug does not exist.
      634424ca
    • igor@rurik.mysql.com's avatar
      select.result: · 4ef431ad
      igor@rurik.mysql.com authored
        Adjusted results of the test case for bug #7520 for 4.1.
      4ef431ad
    • igor@rurik.mysql.com's avatar
      select.result, select.test: · 8b3d59ad
      igor@rurik.mysql.com authored
        Added a test case for bug #7520.
      table.cc:
        Fixed bug #7520.
        The bug was caused by a wrong calculation of the field max_key_length for
        a TABLE structure when there was an index on a blob field.
      8b3d59ad
  31. 28 Nov, 2004 1 commit
  32. 26 Nov, 2004 1 commit
  33. 16 Nov, 2004 1 commit
  34. 07 Oct, 2004 1 commit
    • monty@mysql.com's avatar
      After merge fixes · 6239edc1
      monty@mysql.com authored
      Some bigger code changes was necessary becasue of the multi-table-update and the new HANDLER code
      6239edc1
  35. 07 Sep, 2004 1 commit
  36. 03 Sep, 2004 1 commit
    • igor@rurik.mysql.com's avatar
      select.result, select.test: · f888026f
      igor@rurik.mysql.com authored
        Added a test case for bug #5333.
      null_key.result, key_primary.result:
        Made covering index usable for const tables.
      sql_select.cc:
        Made covering index usable for const tables:
        downported the corresponding code from 4.1.
        Simultaneously fixed bug #5333 reported for 4.1.
        The bug was due to the fact that field index in join
        structures was always set to 0 for const tables.
      f888026f