An error occurred fetching the project authors.
  1. 24 Jun, 2010 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug #54459: Assertion failed: param.sort_length, · f11940d0
      Ramil Kalimullin authored
      file .\filesort.cc, line 149 (part II)
      
      Problem: the server didn't disregard sort order 
      for some zero length tuples.
      
      Fix: skip sort order in such a case 
      (zero length NOT NULL string functions).
      
      
      mysql-test/r/select.result:
        Fix for bug #54459: Assertion failed: param.sort_length, 
        file .\filesort.cc, line 149 (part II)
          - test result.
      mysql-test/t/select.test:
        Fix for bug #54459: Assertion failed: param.sort_length, 
        file .\filesort.cc, line 149 (part II)
          - test case.
      sql/sql_select.cc:
        Fix for bug #54459: Assertion failed: param.sort_length, 
        file .\filesort.cc, line 149 (part II)
          - disregard sort order for zero length NOT NULL string functions
        along with zero length NOT NULL fields.
      f11940d0
  2. 24 Mar, 2010 1 commit
    • MySQL Build Team's avatar
      Backport into build-201003230706-5.1.43sp1 · 80bf070d
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 3333.1.7 [merge]
      > revision-id: ramil@mysql.com-20100129110849-1nm85j95594epnme
      > parent: joro@sun.com-20100129093628-sze9cv0neu0xbabm
      > parent: ramil@mysql.com-20100129091757-81r640na2t5bzbiz
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: mysql-5.1-bugteam
      > timestamp: Fri 2010-01-29 15:08:49 +0400
      > message:
      >   Auto-merge.
      > ------------------------------------------------------------
      > Use --include-merges or -n0 to see merged revisions.
      80bf070d
  3. 03 Feb, 2010 3 commits
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · 79a87cd7
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.1.26
      > revision-id: joro@sun.com-20091109140946-07wao5od7l1vn4x1
      > parent: joro@sun.com-20091110082141-ldr8p6s1joczve2j
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B48458-5.0-bugteam
      > timestamp: Mon 2009-11-09 16:09:46 +0200
      > message:
      >   Bug #48458: simple query tries to allocate enormous amount of
      >     memory
      >   
      >   The server was doing a bad class typecast causing setting of 
      >   wrong value for the maximum number of items in an internal
      >   structure used in equality propagation.
      >   Fixed by not doing the wrong typecast and asserting the type
      >   of the Item where it should be done.
      79a87cd7
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · 3805ed8f
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.1.13
      > revision-id: joro@sun.com-20091030131543-2b23fnqckgbzvete
      > parent: joro@sun.com-20091030094044-quadg0bwjy7cwqzw
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B48291-5.0-bugteam
      > timestamp: Fri 2009-10-30 15:15:43 +0200
      > message:
      >   Bug #48291 : crash with row() operator,select into @var, and 
      >     subquery returning multiple rows
      >   
      >   Error handling was missing when handling subqueires in WHERE 
      >   and when assigning a SELECT result to a @variable.
      >   This caused crash(es). 
      >   
      >   Fixed by adding error handling code to both the WHERE 
      >   condition evaluation and to assignment to an @variable.
      3805ed8f
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · 9e6ba65b
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.1.4
      > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c
      > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: b47019-5.0-bugteam
      > timestamp: Wed 2009-10-21 14:04:08 +0500
      > message:
      >   Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
      >   line 138 when forcing a spatial index
      >   
      >   Problem: "Spatial indexes can be involved in the search 
      >   for queries that use a function such as MBRContains() 
      >   or MBRWithin() in the WHERE clause".
      >   Using spatial indexes for JOINs with =, <=> etc.
      >   predicates is incorrect.
      >   
      >   Fix: disable spatial indexes for such queries.
      9e6ba65b
  4. 29 Jan, 2010 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL · 57f9915f
      Ramil Kalimullin authored
      column is used for ORDER BY
      
      Problem: filesort isn't meant for null length sort data
      (e.g. char(0)), that leads to a server crash.
      
      Fix: disregard sort order if sort data record length is 0 (nothing
      to sort).
      
      
      mysql-test/r/select.result:
        Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL 
        column is used for ORDER BY
          - test result.
      mysql-test/t/select.test:
        Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL 
        column is used for ORDER BY
          - test case.
      sql/filesort.cc:
        Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL 
        column is used for ORDER BY
          - assert added as filesort cannot handle null length sort data.
      sql/sql_select.cc:
        Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL 
        column is used for ORDER BY
          - don't sort null length data e.g. in case of ORDER BY CHAR(0).
      57f9915f
  5. 15 Dec, 2009 2 commits
    • Ramil Kalimullin's avatar
      Fix for bug#49517: Inconsistent behavior while using · 4cb5f047
      Ramil Kalimullin authored
      NULLable BIGINT and INT columns in comparison
      
      Problem: a consequence of the fix for 43668.
      Some Arg_comparator inner initialization missed,
      that may lead to unpredictable (wrong) comparison
      results.
      
      Fix: always properly initialize Arg_comparator
      before its usage.
      
      
      mysql-test/r/select.result:
        Fix for bug#49517: Inconsistent behavior while using 
        NULLable BIGINT and INT columns in comparison
          -test result.
      mysql-test/t/select.test:
        Fix for bug#49517: Inconsistent behavior while using 
        NULLable BIGINT and INT columns in comparison
          -test case.
      sql/item_cmpfunc.cc:
        Fix for bug#49517: Inconsistent behavior while using 
        NULLable BIGINT and INT columns in comparison
          - now all Arg_comparator::set_cmp_func() set
        Arg_comparator::set_null to ensure its proper initialization
        in all cases (by default it's set to TRUE in constructors).
      sql/item_cmpfunc.h:
        Fix for bug#49517: Inconsistent behavior while using 
        NULLable BIGINT and INT columns in comparison
          - now all Arg_comparator::set_cmp_func() set
        Arg_comparator::set_null to ensure its proper initialization
        in all cases (by default it's set to TRUE in constructors).
      4cb5f047
    • Georgi Kodinov's avatar
      Bug#49489: Uninitialized cache led to a wrong result. · 6c37da5a
      Georgi Kodinov authored
      Merge the fix from 5.1-bugteam to 5.1-main
      6c37da5a
  6. 09 Dec, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#49489: Uninitialized cache led to a wrong result. · cda91c21
      Evgeny Potemkin authored
      Arg_comparator uses Item_cache objects to store constants being compared when
      they're need a type conversion. Because this cache wasn't initialized properly
      Arg_comparator might produce wrong comparison result.
      
      The Arg_comparator::cache_converted_constant function now initializes cache
      prior to usage.
      
      mysql-test/r/select.result:
        Added a test case for he bug#49489.
      mysql-test/t/select.test:
        Added a test case for he bug#49489.
      sql/item_cmpfunc.cc:
        Bug#49489: Uninitialized cache led to a wrong result.
        The Arg_comparator::cache_converted_constant function now initializes cache
        prior to usage.
      cda91c21
  7. 04 Dec, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#49199: Optimizer handles incorrectly: · cb744ed9
      Ramil Kalimullin authored
      field='const1' AND field='const2' in some cases
      
      Building multiple equality predicates containing
      a constant which is compared as a datetime (with a field)
      we should take this fact into account and compare the 
      constant with another possible constatns as datetimes 
      as well.
      
      E.g. for the
      SELECT ... WHERE a='2001-01-01' AND a='2001-01-01 00:00:00'
      we should compare '2001-01-01' with '2001-01-01 00:00:00' as
      datetimes but not as strings.
      
      
      mysql-test/r/select.result:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - test result.
      mysql-test/t/select.test:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - test case.
      sql/item_cmpfunc.cc:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - adding a constant to Item_equal compare it as
        a datetime value with stored one if there's a 
        date[time] field in a equality predicate.
      sql/item_cmpfunc.h:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - adding a constant to Item_equal compare it as
        a datetime value with stored one if there's a 
        date[time] field in a equality predicate.
      sql/sql_select.cc:
        Fix for bug#49199: Optimizer handles incorrectly: 
        field='const1' AND field='const2' in some cases
          - adding a constant to Item_equal compare it as
        a datetime value with stored one if there's a 
        date[time] field in a equality predicate.
      cb744ed9
  8. 25 Nov, 2009 2 commits
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · 196d564a
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 1810.3961.7
      > committer: Georgi Kodinov <joro@sun.com>
      > branch nick: B48291-5.0-bugteam
      > timestamp: Fri 2009-10-30 15:15:43 +0200
      > message:
      >   Bug #48291 : crash with row() operator,select into @var, and
      >     subquery returning multiple rows
      >
      >   Error handling was missing when handling subqueires in WHERE
      >   and when assigning a SELECT result to a @variable.
      >   This caused crash(es).
      >
      >   Fixed by adding error handling code to both the WHERE
      >   condition evaluation and to assignment to an @variable.
      > ------------------------------------------------------------
      196d564a
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · a58a5e32
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 1810.3959.4
      > revision-id: ramil@mysql.com-20091021090408-208mvwwrcroi2j8c
      > parent: azundris@mysql.com-20091021033856-ydodp4q42o58e7ka
      > committer: Ramil Kalimullin <ramil@mysql.com>
      > branch nick: b47019-5.0-bugteam
      > timestamp: Wed 2009-10-21 14:04:08 +0500
      > message:
      >   Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
      >   line 138 when forcing a spatial index
      >   
      >   Problem: "Spatial indexes can be involved in the search 
      >   for queries that use a function such as MBRContains() 
      >   or MBRWithin() in the WHERE clause".
      >   Using spatial indexes for JOINs with =, <=> etc.
      >   predicates is incorrect.
      >   
      >   Fix: disable spatial indexes for such queries.
      a58a5e32
  9. 13 Nov, 2009 1 commit
    • Jorgen Loland's avatar
      Bug#48052: Valgrind warning - uninitialized value in · dc61ff1f
      Jorgen Loland authored
                 init_read_record() - (records.cc:274)
            
      Item_cond::used_tables_cache was accessed in
      records.cc#init_read_record() without being initialized. It had
      not been initialized because it was wrongly assumed that the
      Item's variables would not be accessed, and hence
      quick_fix_field() was used instead of fix_fields() to save a few
      CPU cycles at creation time.
      
      The fix is to properly initilize the Item by replacing
      quick_fix_field() with fix_fields().
      
      
      mysql-test/r/select.result:
        Add test for BUG#48052
      mysql-test/t/select.test:
        Add test for BUG#48052
      sql/sql_select.cc:
        Properly initialize Item_cond_and by calling fix_fields (instead of quick_fix_field) when the Item that "ANDs" WHERE clause conditions with HAVING clause conditions is created.
      dc61ff1f
  10. 09 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48458: simple query tries to allocate enormous amount of · d4e4f95a
      Georgi Kodinov authored
        memory
      
      The server was doing a bad class typecast causing setting of 
      wrong value for the maximum number of items in an internal
      structure used in equality propagation.
      Fixed by not doing the wrong typecast and asserting the type
      of the Item where it should be done.
      d4e4f95a
  11. 30 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48291 : crash with row() operator,select into @var, and · 16d0f7f9
      Georgi Kodinov authored
        subquery returning multiple rows
      
      Error handling was missing when handling subqueires in WHERE 
      and when assigning a SELECT result to a @variable.
      This caused crash(es). 
      
      Fixed by adding error handling code to both the WHERE 
      condition evaluation and to assignment to an @variable.
      16d0f7f9
  12. 21 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, · 5e3f89fd
      Ramil Kalimullin authored
      line 138 when forcing a spatial index
      
      Problem: "Spatial indexes can be involved in the search 
      for queries that use a function such as MBRContains() 
      or MBRWithin() in the WHERE clause".
      Using spatial indexes for JOINs with =, <=> etc.
      predicates is incorrect.
      
      Fix: disable spatial indexes for such queries.
      
      
      mysql-test/r/select.result:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - test result.
      mysql-test/t/select.test:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - test case.
      sql/sql_select.cc:
        Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, 
        line 138 when forcing a spatial index
          - disable spatial indexes for queries which use 
        non-spatial conditions (e.g. NATURAL JOINs).
      5e3f89fd
  13. 26 Jun, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#45266: Uninitialized variable lead to an empty result. · 72d020a2
      Evgeny Potemkin authored
      The TABLE::reginfo.impossible_range is used by the optimizer to indicate
      that the condition applied to the table is impossible. It wasn't initialized
      at table opening and this might lead to an empty result on complex queries:
      a query might set the impossible_range flag on a table and when the query finishes,
      all tables are returned back to the table cache. The next query that uses the table
      with the impossible_range flag set and an index over the table will see the flag
      and thus return an empty result.
      
      The open_table function now initializes the TABLE::reginfo.impossible_range
      variable.
      
      mysql-test/r/select.result:
        A test case for the bug#45266: Uninitialized variable lead to an empty result.
      mysql-test/t/select.test:
        A test case for the bug#45266: Uninitialized variable lead to an empty result.
      sql/sql_base.cc:
        Bug#45266: Uninitialized variable lead to an empty result.
        The open_table function now initializes the TABLE::reginfo.impossible_range
        variable.
      sql/sql_select.cc:
        Bug#45266: Uninitialized variable lead to an empty result.
        The open_table function now initializes the TABLE::reginfo.impossible_range
        variable.
      sql/structs.h:
        Bug#45266: Uninitialized variable lead to an empty result.
        A comment is added.
      72d020a2
  14. 28 Apr, 2009 1 commit
    • Gleb Shchepa's avatar
      backport from 6.0: · 5e2fe847
      Gleb Shchepa authored
      Bug #40925: Equality propagation takes non indexed attribute
      
      Query execution plans and execution time of queries like
      
        select a, b, c from t1
          where a > '2008-11-21' and b = a limit 10
      
      depended on the order of equality operator parameters:
      "b = a" and "a = b" are not same. 
      
      
      An equality propagation algorithm has been fixed:
      the substitute_for_best_equal_field function should not
      substitute a field for an equal field if both fields belong
      to the same table.
      
      
      mysql-test/r/select.result:
        Added test case for bug #40925.
      mysql-test/t/select.test:
        Added test case for bug #40925.
      sql/item.cc:
        Bug #40925: Equality propagation takes non indexed attribute
        
        An equality propagation algorithm has been fixed:
        the substitute_for_best_equal_field function should not 
        substitute a field for an equal field if both fields belong
        to the same table.
      5e2fe847
  15. 16 Mar, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug #42957: no results from · c8d4498e
      Ramil Kalimullin authored
      select where .. (col=col and col=col) or ... (false expression)
      
      Problem: optimizer didn't take into account a singular case 
      when we eliminated all the predicates at the AND level of WHERE.
      That may lead to wrong results.
      
      Fix: replace (a=a AND a=a...) with TRUE if we eliminated all the
      predicates.
      
      
      mysql-test/r/select.result:
        Fix for bug #42957: no results from 
        select where .. (col=col and col=col) or ... (false expression)
          - test result.
      mysql-test/t/select.test:
        Fix for bug #42957: no results from 
        select where .. (col=col and col=col) or ... (false expression)
          - test case.
      sql/sql_select.cc:
        Fix for bug #42957: no results from 
        select where .. (col=col and col=col) or ... (false expression)
          - replacing equality predicates by multiple equality items check
        if we eliminate all the predicates at the AND level and 
        replace them with TRUE if so.
      c8d4498e
  16. 24 Dec, 2008 1 commit
    • Sergey Glukhov's avatar
      Bug#40953 SELECT query throws "ERROR 1062 (23000): Duplicate entry..." error · 4c689750
      Sergey Glukhov authored
      Table could be marked dependent because it is
      either 1) an inner table of an outer join, or 2) it is a part of
      STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not
      be assigned. The fix is to set st_table::maybe_null to 'true' only
      for those tables which are used in outer join.
      
      
      
      mysql-test/r/select.result:
        test result
      mysql-test/t/select.test:
        test case
      sql/sql_select.cc:
        Table could be marked dependent because it is
        either 1) an inner table of an outer join, or 2) it is a part of
        STRAIGHT_JOIN. In case of STRAIGHT_JOIN table->maybe_null should not
        be assigned. The fix is to set st_table::maybe_null to 'true' only
        for those tables which are used in outer join.
      sql/sql_select.h:
        added comment
      4c689750
  17. 09 Dec, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #37936: ASSERT_COLUMN_MARKED_FOR_WRITE in Field_datetime::store , · d44d9aae
      Georgi Kodinov authored
      Field_varstring::store
            
      The code that temporary saved the bitmaps of the read set and the write set so that
      it can set it to all columns for debug purposes was not expecting that the
      table->read_set and table->write_set can be the same. And was always saving both in 
      sequence.
      As a result the original value was never restored.
      Fixed by saving & restoring the original value only once if the two sets are the
      same (in a special set of functions).
      
      mysql-test/r/select.result:
        Bug #37936: test case
      mysql-test/t/select.test:
        Bug #37936: test case
      sql/item_cmpfunc.cc:
        Bug #37936: don't save/restore twice if the read and write sets are the same
      sql/opt_range.cc:
        Bug #37936: don't save/restore twice if the read and write sets are the same
      sql/table.h:
        Bug #37936: Make a designated set of functions that save/restore
        both the read and the write sets in a single call.
      d44d9aae
  18. 17 Feb, 2008 1 commit
    • unknown's avatar
      Bug #32942 now() - interval '7200' second NOT pre-calculated, causing "full table scan" · 274cdcdd
      unknown authored
      Problem is not about intervals and doesn't actually cause 'full table scan'.
      We have an optimization for DISTINCT when we have
      'DISTINCT field_from_first_join_table' we don't need to read all the
      rows from the JOIN-ed table if we found one conforming row.
      It stopped working in 5.0 as we return NESTED_LOOP_OK if we came upon
      that case in the evaluate_join_record() and that doesn't break the
      recordreading loop in sub_select().
      
      Fixed by returning NESTED_LOOP_NO_MORE_ROWS in this case.
      
      
      mysql-test/r/select.result:
        Bug #32942 now() - interval '7200' second is NOT pre-calculated, causing "full table scan".
        
        test result
      mysql-test/t/select.test:
        Bug #32942 now() - interval '7200' second is NOT pre-calculated, causing "full table scan"
        
        test case
      sql/sql_select.cc:
        Bug #32942 now() - interval '7200' second NOT pre-calculated, causing "full table scan"
        
        return NESTED_LOOP_NO_MORE_ROWS when we don't need to read rows from
        this table anymore
      274cdcdd
  19. 13 Feb, 2008 1 commit
    • unknown's avatar
      Fixed bug#33764: Wrong result with IN(), CONCAT() and implicit · cb5c4940
      unknown authored
                       type conversion.
      
      Instead of copying of whole character string from a temporary
      buffer, the server copied a short-living pointer to that string
      into a long-living structure. That has been fixed.
      
      
      mysql-test/r/select.result:
        Added test case for bug#33764.
      mysql-test/t/select.test:
        Added test case for bug#33764.
      sql/item_cmpfunc.cc:
        Fixed bug#33764.
        Copying of a pointer has been replaced with an optional copying of
        a whole array to a newly allocated memory space in case of a
        functional source item.
      cb5c4940
  20. 17 Nov, 2007 1 commit
    • unknown's avatar
      Fixed bug #32335. · 8aa822ee
      unknown 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.
      
      
      sql/item_cmpfunc.cc:
        Fixed bug #32335.
        1. 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.
        
        2. Also minor bug has been fixed: the thd->count_cuted_fields value
           was not restored in case of successful conversion.
      mysql-test/t/select.test:
        Added test case for bug #32335.
      mysql-test/r/select.result:
        Added test case for bug #32335.
      8aa822ee
  21. 14 Nov, 2007 1 commit
  22. 10 Nov, 2007 1 commit
    • unknown's avatar
      Bug#31800: Date comparison fails with timezone and slashes for greater than comparison · 2cb9a44c
      unknown authored
      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.
      
      
      mysql-test/r/select.result:
        Show that we compare DATE/DATETIME-like strings as date(time)s
        now, rather than as bin-strings.
        Adjust older result as "2005-09-3a" is now correctly seen as
        "2005-09-3" + trailing garbage, rather than as "2005-09-30".
      mysql-test/t/select.test:
        Show that we compare DATE/DATETIME-like strings as date(time)s
        now, rather than as bin-strings.
      sql-common/my_time.c:
        correct/clarify date-related comments, particulary for check_date().
        doxygenize comment while at it.
      sql/item_cmpfunc.cc:
        get_date_from_str() no longer signals an error when all we had
        was a warning-condition -- and one we already gave the user a
        warning for at that. Preamble doxygenized.
      2cb9a44c
  23. 07 Nov, 2007 2 commits
    • unknown's avatar
      Fix for bug #32103: optimizer crash when join on int and mediumint with · 70cbef8e
      unknown 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).
      
      
      mysql-test/r/select.result:
        Added a test case for bug #32103.
      mysql-test/t/select.test:
        Added a test case for bug #32103.
      sql/item.h:
        Use the correct constructor for Item_uint in Item_uint::new_item().
      70cbef8e
    • unknown's avatar
      Fix for bug #30666: Incorrect order when using range conditions on 2 · 00c125ee
      unknown authored
      tables or more
      
      The problem was that the optimizer used the join buffer in cases when
      the result set is ordered by filesort. This resulted in the ORDER BY
      clause being ignored, and the records being returned in the order
      determined by the order of matching records in the last table in join.
      
      Fixed by relaxing the condition in make_join_readinfo() to take
      filesort-ordered result sets into account, not only index-ordered ones.
      
      
      mysql-test/r/select.result:
        Added a test case for bug #30666.
      mysql-test/t/select.test:
        Added a test case for bug #30666.
      sql/sql_select.cc:
        Relaxed the condition to determine when the join buffer usage must be
        disabled. The condition is now true for cases when the result set is
        ordered by filesort, that is when 'join->order &&
        !join->skip_sort_order' is true.
      00c125ee
  24. 25 Oct, 2007 1 commit
    • unknown's avatar
      Fixed bug #27695: View should not be allowed to have empty or · afa6e70a
      unknown authored
      all space column names.
      
      The parser has been modified to check VIEW column names
      with the check_column_name function and to report an error
      on empty and all space column names (same as for TABLE
      column names).
      
      
      sql/sql_yacc.yy:
        Fixed bug #27695.
        The parser has been modified to check VIEW column aliases
        with the check_column_name function and to report an error
        on empty columns and all space columns (same as for TABLE
        column names).
      mysql-test/t/select.test:
        Updated test case for bug #27695.
      mysql-test/r/select.result:
        Updated test case for bug #27695.
      afa6e70a
  25. 23 Oct, 2007 1 commit
    • unknown's avatar
      Patch for BUG#30736: Row Size Too Large Error Creating a Table and · cfa54d6d
      unknown authored
      Inserting Data.
      
      The problem was that under some circumstances Field class was not
      properly initialized before calling create_length_to_internal_length()
      function, which led to assert failure.
      
      The fix is to do the proper initialization.
      
      The user-visible problem was that under some circumstances
      CREATE TABLE ... SELECT statement crashed the server or led
      to wrong error message (wrong results).
      
      
      mysql-test/r/select.result:
        Update result file.
      mysql-test/t/select.test:
        Add a test case for BUG#30736: Row Size Too Large Error
        Creating a Table and Inserting Data.
      sql/sql_table.cc:
        Move sql_field->decimals initialization before
        sql_field->create_length_to_internal_length() call.
      cfa54d6d
  26. 19 Sep, 2007 1 commit
    • unknown's avatar
      Bug #30639: limit offset,rowcount wraps when rowcount >= 2^32 in windows · 0d0d804f
      unknown authored
       The parser uses ulonglong to store the LIMIT number. This number
       then is stored into a variable of type ha_rows. ha_rows is either
       4 or 8 byte depending on the BIG_TABLES define from config.h
       So an overflow may occur (and LIMIT becomes zero) while storing an
       ulonglong value in ha_rows.
       Fixed by :
        1. Using the maximum possible value for ha_rows on overflow
        2. Defining BIG_TABLES for the windows builds (to match the others) 
      
      
      include/config-win.h:
        Bug #30639: turn on BIG_TABLES for windows
      mysql-test/r/select.result:
        Bug #30639: test case
      mysql-test/t/select.test:
        Bug #30639: test case
      sql/sql_lex.cc:
        Bug #30639: Use the maximum possible number on overflow 
         of LIMIT. This is valid because there won't be more rows
         anyway.
      0d0d804f
  27. 15 Sep, 2007 1 commit
    • unknown's avatar
      select.test: · 6bcc6c25
      unknown authored
        Post-fix for bug#27695.
      
      
      mysql-test/t/select.test:
        Post-fix for bug#27695.
      6bcc6c25
  28. 13 Sep, 2007 1 commit
    • unknown's avatar
      Fixed bug #27695. · ede3c722
      unknown authored
      Declaring an all space column name in the SELECT FROM DUAL or in a view
      leads to misleading warning message:
      "Leading spaces are removed from name ' '".
      
      The Item::set_name method has been modified to raise warnings like
      "Name ' ' has become ''" in case of the truncation of an all
      space identifier to an empty string identifier instead of the
      "Leading spaces are removed from name ' '" warning message.
      
      
      sql/item.cc:
        Fixed bug #27695.
        The Item::set_name method has been modified to raise warnings like
        "Name ' ' has become ''" in case of the truncation of an all
        space identifier to an empty string identifier instead of the
        "Leading spaces are removed from name ' '" warning message.
      sql/share/errmsg.txt:
        Fixed bug #27695.
      mysql-test/t/select.test:
        Added test case for bug #27695.
      mysql-test/r/select.result:
        Added test case for bug #27695.
      ede3c722
  29. 23 Aug, 2007 1 commit
    • unknown's avatar
      Fixed bug #30396. · 64c17322
      unknown authored
      Recommit to 5.1.22.
      The bug caused memory corruption for some queries with top OR level
      in the WHERE condition if they contained equality predicates and 
      other sargable predicates in disjunctive parts of the condition.
      
      The corruption happened because the upper bound of the memory
      allocated for KEY_FIELD and SARGABLE_PARAM internal structures
      containing info about potential lookup keys was calculated incorrectly
      in some cases. In particular it was calculated incorrectly when the
      WHERE condition was an OR formula with disjuncts being AND formulas
      including equalities and other sargable predicates.
      
      
      mysql-test/r/select.result:
        Added a test case for bug #30396.
        Recommit to 5.1.22.
      mysql-test/t/select.test:
        Added a test case for bug #30396.
        Recommit to 5.1.22.
      sql/item_cmpfunc.h:
        Removed max_members from the COND_EQUAL class as not useful anymore. 
        Recommit to 5.1.22.
      sql/sql_base.cc:
        Added the max_equal_elems field to the st_select_lex structure.
        Recommit to 5.1.22.
      sql/sql_lex.cc:
        Added the max_equal_elems field to the st_select_lex structure.
        Recommit to 5.1.22.
      sql/sql_lex.h:
        Added the max_equal_elems field to the st_select_lex structure.
        The field contains the maximal number of elements in multiple equalities
        built for the query conditions.
        Recommit to 5.1.22.
      sql/sql_select.cc:
        Fixed bug #30396.
        Recommit to 5.1.22.
        The bug caused memory corruption for some queries with top OR level
        in the WHERE condition if they contained equality predicates and 
        other sargable predicates in disjunctive parts of the condition.
        
        The corruption happened because the upper bound of the memory
        allocated for KEY_FIELD and SARGABLE_PARAM internal structures
        containing info about potential lookup keys was calculated incorrectly
        in some cases. In particular it was calculated incorrectly when the
        WHERE condition was an OR formula with disjuncts being AND formulas
        including equalities and other sargable predicates.
         
        The max_equal_elems field to the st_select_lex structure is used now
        to calculate the above mentioned upper bound. The field contains the
        maximal number of elements in multiple equalities built for the query
        conditions.
      64c17322
  30. 15 Aug, 2007 1 commit
    • unknown's avatar
      Fixed bug #30396. · 42a6a150
      unknown authored
      The bug caused memory corruption for some queries with top OR level
      in the WHERE condition if they contained equality predicates and 
      other sargable predicates in disjunctive parts of the condition.
      
      The corruption happened because the upper bound of the memory
      allocated for KEY_FIELD and SARGABLE_PARAM internal structures
      containing info about potential lookup keys was calculated incorrectly
      in some cases. In particular it was calculated incorrectly when the
      WHERE condition was an OR formula with disjuncts being AND formulas
      including equalities and other sargable predicates.
      
      
      mysql-test/r/select.result:
        Added a test case for bug #30396.
      mysql-test/t/select.test:
        Added a test case for bug #30396.
      sql/item_cmpfunc.h:
        Removed max_members from the COND_EQUAL class as not useful anymore.
      sql/sql_base.cc:
        Added the max_equal_elems field to the st_select_lex structure.
      sql/sql_lex.cc:
        Added the max_equal_elems field to the st_select_lex structure.
      sql/sql_lex.h:
        Added the max_equal_elems field to the st_select_lex structure.
        The field contains the maximal number of elements in multiple equalities
        built for the query conditions.
      sql/sql_select.cc:
        Fixed bug #30396.
        The bug caused memory corruption for some queries with top OR level
        in the WHERE condition if they contained equality predicates and 
        other sargable predicates in disjunctive parts of the condition.
        
        The corruption happened because the upper bound of the memory
        allocated for KEY_FIELD and SARGABLE_PARAM internal structures
        containing info about potential lookup keys was calculated incorrectly
        in some cases. In particular it was calculated incorrectly when the
        WHERE condition was an OR formula with disjuncts being AND formulas
        including equalities and other sargable predicates.
         
        The max_equal_elems field to the st_select_lex structure is used now
        to calculate the above mentioned upper bound. The field contains the
        maximal number of elements in multiple equalities built for the query
        conditions.
      42a6a150
  31. 02 Aug, 2007 1 commit
    • unknown's avatar
      Fixed bug #27352. · 45b4a7e3
      unknown authored
      The SELECT query with more than 31 nested dependent SELECT queries returned
      wrong result.
      
      New error message has been added: ER_TOO_HIGH_LEVEL_OF_NESTING_FOR_SELECT.
      It will be reported as: "Too high level of nesting for select".
      
      
      sql/sql_parse.cc:
        Fixed bug #27352.
        The Item_sum::register_sum_func method has been modified to return
        TRUE on exceeding of allowed level of SELECT nesting and to report
        corresponding error message.
      sql/unireg.h:
        Fixed bug #27352.
        Constant definition has been added: maximal allowed level of SELECT nesting.
      mysql-test/t/select.test:
        Updated test case for bug #27352.
      mysql-test/r/select.result:
        Updated test case for bug #27352.
      sql/share/errmsg.txt:
        Fixed bug #27352.
        New error message has been added: ER_TOO_HIGH_LEVEL_OF_NESTING_FOR_SELECT.
      45b4a7e3
  32. 10 Apr, 2007 1 commit
    • unknown's avatar
      Bug #19372: · 0b6979bb
      unknown authored
      Added a test case.
      The problem was fixed by the fix for bug #17379.
      The problem was that because of some conditions 
      the optimizer always preferred range or full index
      scan access methods to lookup access methods even
      when the latter were much cheaper.
      
      
      mysql-test/r/select.result:
        Bug #19372: test case.
        The problem was fixed by the patch for bug #17379
      mysql-test/t/select.test:
        Bug #19372: test case.
        The problem was fixed by the patch for bug #17379
      0b6979bb
  33. 26 Mar, 2007 1 commit
    • unknown's avatar
      WL3527: 5.0 part: · fbf7748f
      unknown authored
      enabled the optional FOR JOIN to all the three
      clauses : USE, FORCE and IGNORE
      
      
      mysql-test/r/select.result:
        WL3527: 5.0 part: test cases
      mysql-test/t/select.test:
        WL3527: 5.0 part: test cases
      fbf7748f
  34. 12 Mar, 2007 1 commit
    • unknown's avatar
      Fixed bug #26963: invalid optimization of the pushdown conditions · bd39e4ba
      unknown authored
      after single-row table substitution could lead to a wrong result set.
      The bug happened because the function Item_field::replace_equal_field
      erroniously assumed that any field included in a multiple equality
      with a constant has been already substituted for this constant.
      This not true for fields becoming constant after row substitutions
      for constant tables.
       
      
      
      mysql-test/r/select.result:
        Added a test case for bug #26963.
      mysql-test/t/select.test:
        Added a test case for bug #26963.
      sql/item.cc:
        Fixed bug #26963: invalid optimization of the pushdown conditions
        after single-row table substitution could lead to a wrong result set.
        The bug happened because the function Item_field::replace_equal_field
        erroneously assumed that any field included in a multiple equality
        with a constant has been already substituted for this constant.
        This not true for fields becoming constant after row substitutions
        for constant tables.
      bd39e4ba
  35. 09 Mar, 2007 1 commit
    • unknown's avatar
      WL#3527: Extend IGNORE INDEX so places where index is ignored can · d59e043b
      unknown authored
               be specified
       5.0 part of the fix. Implements IGNORE INDEX FOR JOIN as a synonym
       of IGNORE INDEX for backward compatibility with the 5.1 fix.
      
      
      mysql-test/r/select.result:
        WL#3527: Extend IGNORE INDEX so places where index is ignored can 
                 be specified
        - test case
      mysql-test/t/select.test:
        WL#3527: Extend IGNORE INDEX so places where index is ignored can 
                 be specified
        - test case
      d59e043b