An error occurred fetching the project authors.
  1. 02 Aug, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug#28404. · cf394292
      igor@olga.mysql.com authored
      This patch adds cost estimation for the queries with ORDER BY / GROUP BY
      and LIMIT. 
      If there was a ref/range access to the table whose rows were required
      to be ordered in the result set the optimizer always employed this access
      though a scan by a different index that was compatible with the required 
      order could be cheaper to produce the first L rows of the result set.
      Now for such queries the optimizer makes a choice between the cheapest
      ref/range accesses not compatible with the given order and index scans
      compatible with it.
      cf394292
  2. 04 Apr, 2007 2 commits
  3. 03 Apr, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #27532: wrong results with ORDER/GROUP BY queries containing · 90aa05d2
      igor@olga.mysql.com authored
      IN/BETWEEN predicates in sorting expressions.
      Wrong results may occur when the select list contains an expression
      with IN/BETWEEN predicate that differs from a sorting expression by
      an additional NOT only.
       
      Added the method Item_func_opt_neg::eq to compare correctly expressions
      containing [NOT] IN/BETWEEN.
      The eq method inherited from the Item_func returns TRUE when comparing
      'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct.  
      90aa05d2
  4. 07 Mar, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #26672: · d2c977a9
      gkodinov/kgeorge@macbook.gmz authored
       DATE/DATETIME values are out of the currently supported
       4 basic value types (INT,STRING,REAL and DECIMAL).
       So expressions (not fields) of compile type DATE/DATETIME are 
       generally considered as STRING values. This is not so
       when they are compared : then they are compared as 
       INTEGER values.
       But the rule for comparison as INTEGERS must be checked
       explicitly each time when a comparison is to be performed.
       filesort is one such place. However there the check was 
       not done and hence the expressions (not fields) of type 
       DATE/DATETIME were sorted by their string representation.
       Fixed to compare them as INTEGER values for filesort.
      d2c977a9
  5. 06 Mar, 2007 1 commit
  6. 09 Feb, 2007 1 commit
    • cmiller@calliope.local.cmiller/calliope.local's avatar
      Bug#25126: Reference to non-existant column in UPDATE...ORDER BY... crashes server · 0733ea74
      "update existingtable set anycolumn=nonexisting order by nonexisting" would crash
      the server.
      
      Though we would find the reference to a field, that doesn't mean we can then use
      it to set some values.  It could be a reference to another field.  If it is NULL, 
      don't try to use it to set values in the Item_field and instead return an error.
      
      Over the previous patch, this signals an error at the location of the error, rather
      than letting the subsequent deref signal it.
      0733ea74
  7. 22 Jan, 2007 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      BUG#16590: Optimized does not do right "const" table pre-read · 9ea140d1
      gkodinov/kgeorge@macbook.gmz authored
       st_table::const_key_parts member is used in determining if
       certain key has a prefix that is compared to constant(s) in
       the query predicates.
       If there's such prefix the index can be used to get the data
       from the remaining suffix columns in sorted order.
       However if a field is compared to another field from a "const"
       table the const_key_parts is not amended.
       This makes the optimizer unable to detect that the key can be 
       used for sorting and adds an extra filesort.
       Fixed by updating const_key_parts after reading in the "const"
       table.
      9ea140d1
  8. 10 Jan, 2007 1 commit
    • igor@olga.mysql.com's avatar
      Fixed bug #25427. · 578fae9d
      igor@olga.mysql.com authored
      In the method Item_field::fix_fields we try to resolve the name of
      the field against the names of the aliases that occur in the select
      list. This is done by a call of the function find_item_in_list.
      When this function finds several occurrences of the field name
      it sends an error message to the error queue and returns 0.
      Yet the code did not take into account that find_item_in_list
      could return 0 and tried to dereference the returned value.
      578fae9d
  9. 17 Nov, 2006 1 commit
  10. 03 Nov, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #22457: Column alias in ORDER BY works, but not if in an expression · 77acba32
      gkodinov/kgeorge@macbook.gmz authored
       The parser is allocating Item_field for references by name in ORDER BY
       expressions. Such expressions however may point not only to Item_field 
       in the select list (or to a table column) but also to an arbitrary Item. 
       This causes Item_field::fix_fields to throw an error about missing 
       column.
       The fix substitutes Item_field for the reference with an Item_ref when 
       not pointing to Item_field.
      77acba32
  11. 29 Sep, 2006 1 commit
  12. 15 Aug, 2006 2 commits
  13. 14 Aug, 2006 1 commit
    • gkodinov/kgeorge@macbook.gmz's avatar
      Bug #21302: Result not properly sorted when using an ORDER BY on a second · 2d9aa1e6
      gkodinov/kgeorge@macbook.gmz authored
                   table in a join
       The optimizer removes redundant columns in ORDER BY. It is considering 
      redundant every reference to const table column, e.g b in :
      create table t1 (a int, b int, primary key(a)); 
      select 1 from t1 order by b where a = 1
      
      But it must not remove references to const table columns if the 
      const table is an outer table because there still can be 2 values :
      the const value and NULL. e.g.:
      create table t1 (a int, b int, primary key(a));
      select t2.b c from t1 left join t1 t2 on (t1.a = t2.a and t2.a = 5) 
        order by c;
      2d9aa1e6
  14. 18 Jul, 2006 1 commit
    • jimw@rama.(none)'s avatar
      Bug #19498: Inconsistent support for DEFAULT in TEXT columns · d18eacc7
      jimw@rama.(none) authored
        When a default of '' was specified for TEXT/BLOB columns, the specification
        was silently ignored. This is presumably to be nice to applications (or
        people) who generate their column definitions in a not-very-clever fashion.
      
        For clarity, doing this now results in a warning, or an error in strict
        mode.
      d18eacc7
  15. 21 Apr, 2006 1 commit
    • igor@rurik.mysql.com's avatar
      Fixed bug #18767. · fc751415
      igor@rurik.mysql.com authored
      The bug caused wrong result sets for union constructs of the form
      (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
      For such queries order lists were concatenated and limit clause was
      completely neglected. 
      fc751415
  16. 23 Aug, 2005 1 commit
    • timour@mysql.com's avatar
      WL#2486 - natural and using join according to SQL:2003 · e0403003
      timour@mysql.com authored
      * Provide backwards compatibility extension to name resolution of
        coalesced columns. The patch allows such columns to be qualified
        with a table (and db) name, as it is in 4.1.
        Based on a patch from Monty.
      
      * Adjusted tests accordingly to test both backwards compatible name
        resolution of qualified columns, and ANSI-style resolution of
        non-qualified columns.
        For this, each affected test has two versions - one with qualified
        columns, and one without. 
      e0403003
  17. 12 Aug, 2005 1 commit
    • timour@mysql.com's avatar
      Implementation of WL#2486 - · a247282a
      timour@mysql.com authored
      "Process NATURAL and USING joins according to SQL:2003".
      
      * Some of the main problems fixed by the patch:
        - in "select *" queries the * expanded correctly according to
          ANSI for arbitrary natural/using joins
        - natural/using joins are correctly transformed into JOIN ... ON
          for any number/nesting of the joins.
        - column references are correctly resolved against natural joins
          of any nesting and combined with arbitrary other joins.
      
      * This patch also contains a fix for name resolution of items
        inside the ON condition of JOIN ... ON - in this case items must
        be resolved only against the JOIN operands. To support such
        'local' name resolution, the patch introduces a stack of
        name resolution contexts used at parse time.
      
      NOTICE:
      - This patch is not complete in the sense that
        - there are 2 test cases that still do not pass -
          one in join.test, one in select.test. Both are marked
          with a comment "TODO: WL#2486".
        - it does not include a new test specific for the task
      a247282a
  18. 26 Jan, 2005 1 commit
  19. 25 Jan, 2005 1 commit
    • igor@rurik.mysql.com's avatar
      order_by.result, order_by.test: · 34fa69a1
      igor@rurik.mysql.com authored
        Added a test case for bug #7672.
      sql_yacc.yy:
        Fixed bug #7672.
        Made queries of the form (SELECT ...) ORDER BY ... to
        be equivalent to SELECT ... ORDER BY ...
      34fa69a1
  20. 18 Jan, 2005 1 commit
  21. 17 Jan, 2005 1 commit
  22. 15 Jan, 2005 1 commit
  23. 06 Jan, 2005 1 commit
    • timour@mysql.com's avatar
      Fix for BUG#7331. · a8f8433c
      timour@mysql.com authored
      The problem was that when a QUICK_SELECT access method is chosen,
      test_if_skip_sort_order() discovered that the index being used
      by the quick select will not deliver tuples in sorted order.
      In this case test_if_skip_sort_order() tried to change the index
      used by the quick select, but it didn't properly set the other
      members of the quick select, and especially the range flags of
      the ranges in QUICK_SELECT::ranges.
      
      The fix re-invokes the function SQL_SELECT::test_quick_select
      to correctly create a valid QUICK_SELECT object.
      a8f8433c
  24. 06 Dec, 2004 1 commit
    • monty@mysql.com's avatar
      Add support for up to VARCHAR (size up to 65535) · 67ce2479
      monty@mysql.com authored
      Renamed HA_VAR_LENGTH to HA_VAR_LENGTH_PART
      Renamed in all files FIELD_TYPE_STRING and FIELD_TYPE_VAR_STRING to MYSQL_TYPE_STRING and MYSQL_TYPE_VAR_STRING to make it easy to catch all possible errors
      Added support for VARCHAR KEYS to heap
      Removed support for ISAM
      Now only long VARCHAR columns are changed to TEXT on demand (not CHAR)
      Internal temporary files can now use fixed length tables if the used VARCHAR columns are short
      67ce2479
  25. 25 Nov, 2004 1 commit
  26. 30 Sep, 2004 1 commit
  27. 09 Sep, 2004 1 commit
    • monty@mysql.com's avatar
      After merge fixes of merge with 4.1 that included the new arena code. · f2829d03
      monty@mysql.com authored
      Fixed (together with Guilhem) bugs in mysqlbinlog regarding --offset
      Prefix addresses with 0x for easier comparisons of debug logs
      Fixed problem where MySQL choosed index-read even if there would be a much better range on the same index
      This fix changed some 'index' queries to 'range' queries in the test suite
      Don't create 'dummy' WHERE clause for trivial WHERE clauses where we can remove the WHERE clause.
      This fix removed of a lot of 'Using where' notes in the test suite.
      Give NOTE instead of WARNING if table/function doesn't exists when using DROP IF EXISTS
      Give NOTE instead of WARNING for safe field-type conversions
      f2829d03
  28. 07 Sep, 2004 1 commit
  29. 20 Aug, 2004 1 commit
  30. 22 Jun, 2004 1 commit
    • sergefp@mysql.com's avatar
      Range optimizer fix: · f874071a
      sergefp@mysql.com authored
      If cost(full_scan_on_shortest_covering_index) < cost(best_range_scan) <  cost(full_table_scan)
        use full_scan_on_shortest_covering_index
      (before this fix best_range_scan was used)
      f874071a
  31. 17 May, 2004 1 commit
  32. 15 May, 2004 1 commit
  33. 29 Mar, 2004 1 commit
  34. 26 Mar, 2004 1 commit
    • Sinisa@sinisa.nasamreza.org's avatar
      order_by.result: · 09d26f0f
      Sinisa@sinisa.nasamreza.org authored
        result of the test case for FORCE INDEX on ORDER BY
      order_by.test:
        test case for FORCE INDEX on ORDER BY
      sql_select.cc:
        Changing behaviour that MySQL server takes FORCE INDEX clause into account when optimising ORDER BY clause
      09d26f0f
  35. 17 Mar, 2004 1 commit
  36. 16 Feb, 2004 1 commit
    • monty@mysql.com's avatar
      After merge fixes · f43093ec
      monty@mysql.com authored
      Added more DBUG statements
      Ensure that we are comparing end space with BINARY strings
      Use 'any_db' instead of '' to mean any database. (For HANDLER command)
      Only strip ' ' when comparing CHAR, not other space-like characters (like \t)
      f43093ec
  37. 31 Jan, 2004 1 commit
  38. 21 Dec, 2003 1 commit