An error occurred fetching the project authors.
  1. 04 May, 2006 1 commit
  2. 01 Apr, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #16504. · af2d79a7
      igor@rurik.mysql.com authored
      Multiple equalities were not adjusted after reading constant tables.
      It resulted in neglecting good index based methods that could be
      used to access of other tables.
      af2d79a7
  3. 11 Jan, 2006 3 commits
    • evgen@moonbone.local's avatar
      Fixed bug #15538: unchecked table absence caused server crash. · 41ef3435
      evgen@moonbone.local authored
      Absence of table in left part of LEFT/RIGHT join wasn't checked before
      name resolution which resulted in NULL dereferencing and server crash.
      
      Modified rules: 
      "table_ref LEFT opt_outer JOIN_SYM table_ref" and "table_ref RIGHT opt_outer 
      JOIN_SYM table_ref"
      NULL check is moved before push_new_name_resolution_context()
      41ef3435
    • evgen@moonbone.local's avatar
      Fixed bug #15347: Wrong result of subselect when records cache and set · 3e23d458
      evgen@moonbone.local authored
      functions are involved.
      
      When subselect is a join with set functions and no record have been found in
      it, end_send_group() sets null_row for all tables in order aggregate functions 
      to calculate their values correctly. Normally this null_row flag is cleared for 
      each table in sub_select(), but flush_cached_records() doesn't do so.
      Due to this all fields from the table processed by flush_cached_records() are 
      always evaluated as nulls and whole select produces wrong result.
      
      flush_cached_records() now clears null_row flag at the very beginning.
      3e23d458
    • evgen@moonbone.local's avatar
      Fixed bug #15633: Evaluation of Item_equal for non-const table caused wrong · 605f62fc
      evgen@moonbone.local authored
      select result
      
      Item equal objects are employed only at the optimize phase. Usually they are not
      supposed to be evaluated.  Yet in some cases we call the method val_int() for
      them. Here we have to take care of restricting the predicate such an object
      represents f1=f2= ...=fn to the projection of known fields fi1=...=fik.
      
      Added a check for field's table being const in Item_equal::val_int().
      If the field's table is not const val_int() just skips that field when
      evaluating Item_equal.
      605f62fc
  4. 09 Dec, 2005 1 commit
  5. 26 Nov, 2005 1 commit
  6. 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
  7. 11 Nov, 2005 1 commit
  8. 03 Nov, 2005 1 commit
  9. 25 Oct, 2005 1 commit
    • timour@mysql.com's avatar
      Fix for BUG#13832 - Unknown column t1.a in 'on clause'. · f5354eba
      timour@mysql.com authored
      The cause for the bug is that the priorities of all rules/terminals
      that process the FROM clause are not fully specified, and the
      parser generator produces a parser that doesn't always parse
      the FROM clause so that JOINs are left-associative. As a result
      the final join tree produced by the parser is incorrect, which
      is the cause for subsequent name resolution to fail.
      f5354eba
  10. 21 Oct, 2005 1 commit
  11. 13 Oct, 2005 4 commits
  12. 12 Oct, 2005 1 commit
  13. 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
  14. 07 Oct, 2005 1 commit
  15. 03 Oct, 2005 1 commit
  16. 30 Sep, 2005 1 commit
    • timour@mysql.com's avatar
      Fix for BUG#13597 - columns in ON condition not resolved if references a table... · 638198e1
      timour@mysql.com authored
      Fix for BUG#13597 - columns in ON condition not resolved if references a table in a nested right join.
      
      The problem was in that when finding the last table reference in a nested join tree,
      the procedure doing the iteration over the right-most branches of a join tree
      was testing for RIGHT JOINs the table reference that represents the join, and not
      the second operand of the JOIN. Currently the information whether a join is LEFT/RIGHT
      is stored not on the join object itself, but on one of its operands.
      638198e1
  17. 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
  18. 20 Sep, 2005 1 commit
    • timour@mysql.com's avatar
      Fix for BUG#13127. · e609eac0
      timour@mysql.com authored
      The problem was in the way table references are pre-filtered when
      resolving a qualified field. When resolving qualified table references
      we search recursively in the operands of the join. If there is
      natural/using join with a merge view, the first call to find_field_in_table_ref
      makes a recursive call to itself with the view as the new table reference
      to search for the column. However the view has both nested_join and
      join_columns != NULL so it skipped the test whether the view name matches
      the field qualifier. As a result the field was found in the view since the
      view already has a field with the same name. Thus the field was incorrectly
      resolved as the view field.
      e609eac0
  19. 15 Sep, 2005 1 commit
    • evgen@moonbone.local's avatar
      Fix bug #12291 Table wasn't reinited for index scan after sequential scan · 097ca8ad
      evgen@moonbone.local authored
      Optimizer did choose "Range checked for each record" for one of the tables.
      For first few loops over that table it choose sequential access, on later
      stage it choose to use index. Because table was previously initialized for 
      sequential access, it skips intitialization for index access, and when
      server tries to retrieve data error occurs.
      
      QUICK_RANGE_SELECT::init() changes so if file already initialized for
      sequential access, it calls ha_rnd_end() and initializes file for index
      access.
      097ca8ad
  20. 12 Sep, 2005 2 commits
  21. 10 Sep, 2005 1 commit
    • timour@mysql.com's avatar
      Fix for BUG#12943. · 7d24bdac
      timour@mysql.com authored
      The problem was that in the first production in rule 'join_table', that
      processes simple cross joins, the parser was processing the second join operand
      before the first one due to unspecified priorities of JOINs. As a result in the
      case of cross joins the parser constructed a tree with incorrect nesting:
      the expression "t1 join t2 join t3 on some_cond" was interpreted as
      "t1 join (t2 join t3 on some_cond)" instead of
      "(t1 join t2) join t3 on some_cond".
      Because of this incorrect nesting the method make_join_on_context picked an
      incorrect table as the first table of the name resolution context.
      
      The solution assignes correct priorities to the related production.
      7d24bdac
  22. 08 Sep, 2005 1 commit
  23. 29 Aug, 2005 1 commit
    • andrey@lmy004.'s avatar
      fix for bug #12841 · 235cde55
      andrey@lmy004. authored
      (Server crash on DO IFNULL(NULL,NULL)
      (fixes also "SELECT CAST(IFNULL(NULL,NULL) as DECIMAL)" unreported
       crash)
      (new revampled fix with suggestions from Igor)
      235cde55
  24. 23 Aug, 2005 5 commits
  25. 22 Aug, 2005 2 commits
  26. 18 Aug, 2005 1 commit
  27. 17 Aug, 2005 1 commit
  28. 16 Aug, 2005 2 commits