An error occurred fetching the project authors.
  1. 02 Apr, 2011 1 commit
    • Sergey Petrunya's avatar
      Make EXPLAIN better at displaying MRR/BKA: · c90d7dda
      Sergey Petrunya authored
      - "Using MRR" is no longer shown with range access.
      - Instead, both range and BKA accesses will show one of the following:
        = "Rowid-ordered scan"
        = "Key-ordered scan"
        = "Key-ordered Rowid-ordered scan"
      depending on whether DS-MRR implementation will do scan keys in order, rowids in order,
      or both.
      - The patch also introduces a way for other storage engines/MRR implementations to
        pass information to EXPLAIN output about the properties of employed MRR scans.
      c90d7dda
  2. 05 Mar, 2011 1 commit
    • Sergey Petrunya's avatar
      BUG#727667 Wrong result with OR + NOT NULL in maria-5.3 · 6aae42a3
      Sergey Petrunya authored
      - put the code that sets HA_NULL_PART bit back
      - Fix test_if_ref/part_of_refkey() so that 
        = NULL-ability of lookup columns does not prevent the equality 
          from being removed (we now have early/late NULLs filtering which 
          will filter out NULL values)
        = equality is not removed if it is ref_or_null access, and the value 
          of the lookup column can alternate between the lookup value and NULL.
      6aae42a3
  3. 27 Jan, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #707848. · 16916e10
      Igor Babaev authored
      This was another bug in the patch for bug 698882. The new
      code from this patch did not ensured that substitutions
      of fields for best equal fields were performed on all
      AND-OR levels. As a result substitutions for best fields
      in some predicates that had been used by the range optimizer
      were not actually performed while range plans could employ
      these substitutions. This could lead to inconsistent data
      structures and ultimately to a crash.
      16916e10
  4. 02 Dec, 2010 1 commit
  5. 18 Oct, 2010 1 commit
  6. 28 Sep, 2010 1 commit
    • Igor Babaev's avatar
      Fixed bug #52636. · ad4271d0
      Igor Babaev authored
      Applied the fix for bug #47217 from the mysql-6.0 codebase.
      The patch adds not null predicates generated for the left parts
      of the equality predicates used for ref accesses. This is done
      for such predicates both in where conditions and on conditions.
      For the where conditions the not null predicates were generated
      but in 5.0/5.1 they actually never were used due to some lame
      merge from 4.1 to 5.0. The fix for bug #47217 made these 
      predicates to be used in the condition pushed to the tables.
      Yet only this patch generates not null predicates for equality
      predicated from on conditions of outer joins.
      This patch introduces a performance regression that can be
      observed on a test case from null_key.test. The regression
      will disappear after the fix for bug #57024 from mariadb-5.1
      is pulled into mariadb-5.3.
      The patch contains many changes in the outputs of the EXPLAIN 
      commands since generated not null predicates are considered as
      parts of the conditions pushed to join tables and may add
      'Usingwhere' in some rows of EXPLAINs where there used
      to be no such comments.
      ad4271d0
  7. 15 Sep, 2010 1 commit
  8. 13 Sep, 2010 1 commit
    • Martin Hansson's avatar
      Bug #50394: Regression in EXPLAIN with index scan, LIMIT, GROUP BY and · d296440d
      Martin Hansson authored
      ORDER BY computed col
            
      GROUP BY implies ORDER BY in the MySQL dialect of SQL. Therefore, when an
      index on the first table in the query is used, and that index satisfies
      ordering according to the GROUP BY clause, the query optimizer estimates the
      number of tuples that need to be read from this index. If there is a LIMIT
      clause, table statistics on tables following this 'sort table' are employed.
      
      There may be a separate ORDER BY clause however, which mandates reading the
      whole 'sort table' anyway. But the previous estimate was left untouched.
      
      Fixed by removing the estimate from EXPLAIN output if GROUP BY is used in
      conjunction with an ORDER BY clause that mandates using a temporary table.
      d296440d
  9. 15 Jul, 2010 1 commit
  10. 15 Dec, 2009 1 commit
    • Sergey Petrunya's avatar
      Backport into MariaDB-5.2 the following: · 3bb037aa
      Sergey Petrunya authored
      WL#2474 "Multi Range Read: Change the default MRR implementation to implement new MRR interface"
      WL#2475 "Batched range read functions for MyISAM/InnoDb"
              "Index condition pushdown for MyISAM/InnoDB"
      Igor's fix from sp1r-igor@olga.mysql.com-20080330055902-07614:
        There could be observed the following problems:
        1. EXPLAIN did not mention pushdown conditions from on expressions in the 
        'extra' column.  As a result if a query had no where conditions pushed 
        down to a table, but had on conditions pushed to this table the 'extra' 
        column in the EXPLAIN for the table missed 'using where'.
        2. Conditions for ref access were not eliminated from on expressions 
        though such conditions were eliminated from the where condition.
      3bb037aa
  11. 07 Dec, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42760: Select doesn't return desired results when we have null values · b19593a5
      Georgi Kodinov authored
      Part 2 : 
      There was a special optimization on the ref access method for 
      ORDER BY ... DESC that was set without actually looking on the type of the 
      selected index for ORDER BY.
      Fixed the SELECT ... ORDER BY .. DESC (it uses a different code path compared
      to the ASC that has been fixed with the previous fix).
      b19593a5
  12. 10 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #42760: Select doesn't return desired results when we have null · b41d9093
      Georgi Kodinov authored
       values
       
       We should re-set the access method functions when changing the access
       method when switching to another index to avoid sorting.
       
       Fixed by doing a little re-engineering : encapsulating all the function
       assignment into a special function and calling it when flipping the 
       indexes.
      b41d9093
  13. 07 Oct, 2009 1 commit
  14. 22 Sep, 2009 1 commit
    • MySQL Build Team's avatar
      Backport into build-200909221805-5.1.37sp1 · 4f1bd338
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3059 [merge]
      > revision-id: martin.hansson@sun.com-20090810140851-aw5peehzdxi4gjja
      > parent: iggy@mysql.com-20090806145453-ion37sfdsldwwjrj
      > parent: martin.hansson@sun.com-20090807115140-7fn6wjx0mrui7zl5
      > committer: Martin Hansson <martin.hansson@sun.com>
      > branch nick: 5.1bt
      > timestamp: Mon 2009-08-10 16:08:51 +0200
      > message:
      >   Merge
      > ------------------------------------------------------------
      > Use --include-merges or -n0 to see merged revisions.
      4f1bd338
  15. 07 Aug, 2009 1 commit
    • Martin Hansson's avatar
      Bug#46454: MySQL wrong index optimisation leads to incorrect result & crashes · 1164f8a6
      Martin Hansson authored
      Problem 1:
      When the 'Using index' optimization is used, the optimizer may still - after
      cost-based optimization - decide to use another index in order to avoid using
      a temporary table. But when this happens, the flag to the storage engine to 
      read index only (not table) was still set. Fixed by resetting the flag in the 
      storage engine and TABLE structure in the above scenario, unless the new index
      allows for the same optimization.
      Problem 2:
      When a 'ref' access method was employed by cost-based optimizer, (when the column
      is non-NULLable), it was assumed that it needed no initialization if 'quick' access
      methods (since they are based on range scan). When ORDER BY optimization overrides 
      the decision, however, it expects to have this initialized and hence crashes. 
      Fixed in 5.1 (was fixed in 6.0 already) by initializing 'quick' even when there's 
      'ref' access. 
      
      mysql-test/r/order_by.result:
        Bug#46454: Test result.
      mysql-test/t/order_by.test:
        Bug#46454: Test case.
      sql/sql_select.cc:
        Bug#46454: 
        Problem 1 fixed in make_join_select()
        Problem 2 fixed in test_if_skip_sort_order()
      sql/table.h:
        Bug#46454: Added comment to field.
      1164f8a6
  16. 16 Oct, 2008 1 commit
    • Gleb Shchepa's avatar
      Bug #39844: Query Crash Mysql Server 5.0.67 · 9f04b596
      Gleb Shchepa authored
      Server crashed during a sort order optimization
      of a dependent subquery:
      
      SELECT
          (SELECT t1.a FROM t1, t2
            WHERE t1.a = t2.b AND t2.a = t3.c
            ORDER BY t1.a)
        FROM t3;
      
      
      Bitmap of tables, that the reference to outer table
      column uses, in addition to the regular table bit
      has the OUTER_REF_TABLE_BIT bit set.
      The only_eq_ref_tables function traverses this map
      bit by bit simultaneously with join->map2table list.
      Obviously join->map2table never contains an entry
      for the OUTER_REF_TABLE_BIT pseudo-table, so the
      server crashed there.
      
      
      The only_eq_ref_tables function has been modified
      to traverse regular table bits only like the
      update_depend_map function (resetting of the
      OUTER_REF_TABLE_BIT there is enough, but
      resetting of the whole set of PSEUDO_TABLE_BITS
      is used there for sure).
      
      
      mysql-test/r/order_by.result:
        Added test case for bug #39844.
      mysql-test/t/order_by.test:
        Added test case for bug #39844.
      sql/sql_select.cc:
        Bug #39844: Query Crash Mysql Server 5.0.67
        
        The only_eq_ref_tables function has been modified
        to traverse regular table bits only like the
        update_depend_map function (resetting of the
        OUTER_REF_TABLE_BIT there is enough, but
        resetting of the whole set of PSEUDO_TABLE_BITS
        is used there for sure).
      9f04b596
  17. 23 Apr, 2008 1 commit
    • unknown's avatar
      Fixed bug#35844. · e038172a
      unknown authored
      The function test_if_skip_sort_order ignored any covering index used for ref
      access of a table in a query with ORDER BY if this index was incompatible 
      with the ORDER BY list and there was another covering index compatible with
      this list. 
      As a result sub-optimal execution plans were chosen for some queries with
      ORDER BY clause. 
      
      
      mysql-test/r/distinct.result:
        Adjusted results after the fix for bug#35844.
      mysql-test/r/order_by.result:
        Added a test case for bug#35844.
      mysql-test/t/order_by.test:
        Added a test case for bug#35844.
      e038172a
  18. 27 Mar, 2008 1 commit
    • unknown's avatar
      Bug #35206: select query result different if the key is indexed or not · 82242b93
      unknown authored
      The code for executing indexed ORDER BY was not setting all the 
      internal fields correctly when selecting to execute ORDER BY over
      and index.
      Fixed by change the access method to one that will use the 
      quick indexed access if one is selected while selecting indexed
      ORDER BY.
      
      
      mysql-test/r/order_by.result:
        Bug #35206: test case
      mysql-test/t/order_by.test:
        Bug #35206: test case
      sql/sql_select.cc:
        Bug #35206: Change the access method when selecting a 
        quick indexed access.
      82242b93
  19. 08 Feb, 2008 1 commit
    • unknown's avatar
      Bug#31590: Wrong error message on sort buffer being too small. · 2c468127
      unknown authored
      The out of memory error was thrown when the sort buffer size were too small.
      This led to a user confusion.
      
      Now filesort throws the error message about sort buffer being too small.
      
      
      mysql-test/t/order_by.test:
        Added a test case for the bug#31590: Wrong error message on sort buffer being too small.
      mysql-test/r/order_by.result:
        Added a test case for the bug#31590: Wrong error message on sort buffer being too small.
      sql/filesort.cc:
        Bug#31590: Wrong error message on sort buffer being too small.
        Now filesort throws the error message about sort buffer being too small
        instead of out of memory error.
      2c468127
  20. 28 Sep, 2007 1 commit
    • unknown's avatar
      Bug#30665: Inconsistent optimization of IGNORE INDEX FOR {ORDER BY|GROUP BY} · ad2fb477
      unknown authored
      The optimizer takes different execution paths during EXPLAIN than SELECT,
      this fix relates only to EXPLAIN, hence no behavior changes.
      The test of sort keys for ORDER BY was prohibited from considering keys
      that were mentioned in IGNORE KEYS FOR ORDER BY. This led to two 
      inconsistencies: One was that IGNORE INDEX FOR GROUP BY and 
      IGNORE INDEX FOR ORDER BY gave apparently different EXPLAINs; the latter 
      erroneously claimed to do filesort. The second inconsistency 
      is that the test of sort keys is called twice, finding a sort key the first
      time but not the second time, leading to the mentioned filesort.
      
      Fixed by making the test of sort keys consider all enabled 
      keys on the table. This test rejects keys that are not covering, and for 
      covering keys the hint should be ignored anyway. 
      
      
      mysql-test/r/group_by.result:
        Bug#30665: Changed test result. The plan gets more efficient here. 
        The output is included in order to show that it is still correct.
      mysql-test/r/order_by.result:
        Bug#30665: Test result
      mysql-test/t/group_by.test:
        Bug#30665: Changed test case to show correctness of changed plan
      mysql-test/t/order_by.test:
        Bug#30665: Test case
      sql/sql_select.cc:
        Bug#30665: 
        - the fix: Give test_if_skip_sort_order all keys not the subset of non-disabled keys.
        - Added comment to test_if_skip_sort_order
      ad2fb477
  21. 05 Aug, 2007 1 commit
  22. 04 Aug, 2007 1 commit
  23. 02 Aug, 2007 1 commit
    • unknown's avatar
      Fixed bug#28404. · bdba4c96
      unknown 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.
      
      
      mysql-test/r/distinct.result:
        Adjusted results for test cases affected fy the fix for bug #28404.
      mysql-test/r/endspace.result:
        Adjusted results for test cases affected fy the fix for bug #28404.
      mysql-test/r/group_by.result:
        Adjusted results for test cases affected fy the fix for bug #28404.
      mysql-test/r/group_min_max.result:
        Adjusted results for test cases affected fy the fix for bug #28404.
      mysql-test/r/innodb.result:
        Adjusted results for test cases affected fy the fix for bug #28404.
      mysql-test/r/innodb_mysql.result:
        Adjusted results for test cases affected fy the fix for bug #28404.
      mysql-test/r/merge.result:
        Adjusted results for test cases affected fy the fix for bug #28404.
      mysql-test/r/order_by.result:
        Added a test case for bug #28404.
      mysql-test/r/select_found.result:
        Adjusted results for test cases affected fy the fix for bug #28404.
      mysql-test/r/subselect.result:
        Adjusted results for test cases affected fy the fix for bug #28404.
      mysql-test/t/distinct.test:
        Changed a test case after adding the fix for bug #28404.
      mysql-test/t/order_by.test:
        Added a test case for bug #28404.
      sql/sql_select.cc:
        Fixed bug#28404.
        This patch adds cost estimation for the queries with ORDER BY / GROUP BY
        and LIMIT. 
        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.
        
        Modified the function test_if_skip_sort_order to make the above mentioned
        choice cost based.
      sql/sql_select.h:
        Fixed bug#28404.
        This patch adds cost estimation for the queries with ORDER BY / GROUP BY
        and LIMIT. 
        Added a new field fot the JOIN_TAB structure.
      bdba4c96
  24. 04 Apr, 2007 2 commits
  25. 03 Apr, 2007 1 commit
    • unknown's avatar
      Fixed bug #27532: wrong results with ORDER/GROUP BY queries containing · c2a369b2
      unknown 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.  
      
      
      mysql-test/r/order_by.result:
        Added a test case for bug #27532.
      mysql-test/t/order_by.test:
        Added a test case for bug #27532.
      sql/item_cmpfunc.cc:
        Fixed bug #27532.
        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.
      sql/item_cmpfunc.h:
        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.
      c2a369b2
  26. 07 Mar, 2007 1 commit
    • unknown's avatar
      Bug #26672: · 7b53360a
      unknown 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.
      
      
      mysql-test/r/order_by.result:
        Bug #26672: test case
      mysql-test/t/order_by.test:
        Bug #26672: test case
      sql/filesort.cc:
        Bug #26672: sort dates/times as integers
      7b53360a
  27. 06 Mar, 2007 1 commit
    • unknown's avatar
      Bug#25376: Incomplete setup of ORDER BY clause results in a wrong result. · 447c074f
      unknown authored
      Functions over sum functions wasn't set up correctly for the ORDER BY clause
      which leads to a wrong order of the result set.
      
      The split_sum_func() function is called now for each ORDER BY item that
      contains a sum function to set it up correctly.
      
      
      mysql-test/t/order_by.test:
        Added a test case for bug#25376: Incomplete setup of ORDER BY clause results in a wrong result.
      mysql-test/r/order_by.result:
        Added a test case for bug#25376: Incomplete setup of ORDER BY clause results in a wrong result.
      sql/sql_select.cc:
        Bug#25376: Incomplete setup of ORDER BY clause results in a wrong result.
        The split_sum_func() function is called now for each ORDER BY item that
        contains a sum function to set it up correctly.
      447c074f
  28. 09 Feb, 2007 1 commit
    • unknown's avatar
      Bug#25126: Reference to non-existant column in UPDATE...ORDER BY... crashes server · eebf1d9a
      unknown authored
      "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.
      
      
      mysql-test/r/order_by.result:
        Verify that all permutations work.
      mysql-test/t/order_by.test:
        Verify that all permutations work.
      sql/item.cc:
        When the field is NULL, don't dereference it when we set_field().  
        Instead, raise an error.
      eebf1d9a
  29. 22 Jan, 2007 1 commit
    • unknown's avatar
      BUG#16590: Optimized does not do right "const" table pre-read · 82bfd109
      unknown 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.
      
      
      mysql-test/r/order_by.result:
        BUG#16590: Optimized does not do right "const" table pre-read
         - test case
      mysql-test/t/order_by.test:
        BUG#16590: Optimized does not do right "const" table pre-read
         - test case
      sql/sql_select.cc:
        BUG#16590: Optimized does not do right "const" table pre-read
         - fill up the const_key_parts structure
      82bfd109
  30. 10 Jan, 2007 1 commit
    • unknown's avatar
      Fixed bug #25427. · e7fb567a
      unknown 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.
      
      
      mysql-test/r/order_by.result:
        Added a test case for bug #25427.
      mysql-test/t/order_by.test:
        Added a test case for bug #25427.
      sql/item.cc:
        Fixed bug #25427.
        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.
      e7fb567a
  31. 17 Nov, 2006 1 commit
  32. 03 Nov, 2006 1 commit
    • unknown's avatar
      Bug #22457: Column alias in ORDER BY works, but not if in an expression · f8ba4f1f
      unknown 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.
      
      
      mysql-test/r/order_by.result:
        Bug #22457: Column alias in ORDER BY works, but not if in an expression
         - test case
      mysql-test/t/order_by.test:
        Bug #22457: Column alias in ORDER BY works, but not if in an expression
         - test case
      sql/item.cc:
        Bug #22457: Column alias in ORDER BY works, but not if in an expression
         - transform the Item_field made by the parser into Item_ref if it 
           doesn't point to Item_field and it is in allowed context
      f8ba4f1f
  33. 29 Sep, 2006 1 commit
  34. 15 Aug, 2006 2 commits
  35. 14 Aug, 2006 1 commit
    • unknown's avatar
      Bug #21302: Result not properly sorted when using an ORDER BY on a second · f087e2c1
      unknown 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;
      
      
      mysql-test/r/join_outer.result:
        Bug #21302: Result not properly sorted when using an ORDER BY on a second 
                    table in a join
         - don't remove columns of const tables in ORDER BY if the const table 
           is an outer table.
      mysql-test/r/order_by.result:
        Bug #21302: Result not properly sorted when using an ORDER BY on a second 
                    table in a join
         - test case
      mysql-test/t/order_by.test:
        Bug #21302: Result not properly sorted when using an ORDER BY on a second 
                    table in a join
         - test case
      sql/sql_select.cc:
        Bug #21302: Result not properly sorted when using an ORDER BY on a second 
                    table in a join
         - don't remove columns of const tables in ORDER BY if the const table 
           is an outer table.
      f087e2c1
  36. 18 Jul, 2006 1 commit
    • unknown's avatar
      Bug #19498: Inconsistent support for DEFAULT in TEXT columns · 8132a6ba
      unknown 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.
      
      
      mysql-test/r/federated.result:
        Update results
      mysql-test/r/fulltext_distinct.result:
        Update results
      mysql-test/r/fulltext_update.result:
        Update results
      mysql-test/r/gis-rtree.result:
        Update results
      mysql-test/r/gis.result:
        Update results
      mysql-test/r/join_outer.result:
        Update results
      mysql-test/r/order_by.result:
        Update results
      mysql-test/r/type_blob.result:
        Add new results
      mysql-test/r/type_ranges.result:
        Update results
      mysql-test/t/type_blob.test:
        Add new test
      sql/field.cc:
        Issue a warning when setting '' as the default on a BLOB/TEXT column,
        and make it an error in strict mode. Also, clarify comments about when
        NO_DEFAULT_VALUE_FLAG is set.
      8132a6ba
  37. 21 Apr, 2006 1 commit
    • unknown's avatar
      Fixed bug #18767. · 3dd2f261
      unknown 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. 
      
      
      mysql-test/r/order_by.result:
        Added a test case for bug #18767.
      mysql-test/t/order_by.test:
        Added a test case for bug #18767.
      sql/sql_lex.h:
        Fixed bug #18767.
        Placed the code the created a fake SELECT_LEX into a separate function.
      sql/sql_parse.cc:
        Fixed bug #18767.
        Placed the code the created a fake SELECT_LEX into a separate function.
      sql/sql_select.cc:
        Fixed bug #18767.
        Changed the condition on which a SELECT is treated as part of a UNION.
        The SELECT in 
        (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 
        now is handled in the same way as the first SELECT in a UNION
        sequence.
      sql/sql_union.cc:
        Fixed bug #18767.
        Changed the condition at which a SELECT is treated as part of a UNION.
        The SELECT in 
        (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 
        now is handled in the same way as the first SELECT in a UNION
        sequence.
      sql/sql_yacc.yy:
        Fixed bug #18767.
        Changed the condition at which a SELECT is treated as part of a UNION.
        The SELECT in 
        (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 
        now is handled in the same way as the first SELECT in a UNION
        sequence. In the same way is handled the SELECT in
        (SELECT ... LIMIT n) ORDER BY order list.
        Yet if there is neither ORDER BY nor LIMIT in the single-select
        union construct
        (SELECT ...) ORDER BY order_list
        then it is still handled as simple select with an order clause.
      3dd2f261
  38. 23 Aug, 2005 1 commit
    • unknown's avatar
      WL#2486 - natural and using join according to SQL:2003 · 1647932c
      unknown 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. 
      
      
      mysql-test/include/ps_query.inc:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/bdb.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/innodb.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/join.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/join_nested.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/join_outer.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/null_key.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/order_by.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/ps_2myisam.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/ps_3innodb.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/ps_4heap.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/ps_5merge.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/ps_6bdb.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/ps_7ndb.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/select.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/subselect.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/r/type_ranges.result:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/t/bdb.test:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/t/innodb.test:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/t/join.test:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/t/join_nested.test:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/t/join_outer.test:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/t/null_key.test:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/t/order_by.test:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/t/select.test:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/t/subselect.test:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      mysql-test/t/type_ranges.test:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      sql/sql_base.cc:
        * Applied Monty's patch for backwards compatible name resolution
          of qualified columns. The idea is:
          - When a column is qualified, search for the column in all
            tables/views underlying each natural join. In this case
            natural joins are *not* considered leaves.
          - If a column is not qualified, then consider natural joins
            as leaves, thus directly search the result columns of
            natural joins.
        * Simplified 'find_field_in_tables()' - unified two similar
          loops into one.
      sql/table.cc:
        - Removed method & members not needed after Monty's patch.
      sql/table.h:
        - Removed method & members not needed after Monty's patch.
      tests/mysql_client_test.c:
        Put back old tests to test that coalesced columns of natural joins can be qualified.
      1647932c