An error occurred fetching the project authors.
  1. 04 May, 2011 1 commit
  2. 02 Apr, 2011 1 commit
    • Sergey Petrunya's avatar
      Make EXPLAIN better at displaying MRR/BKA: · 997445bc
      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.
      997445bc
  3. 26 Jan, 2011 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #707555. · a624f99e
      Igor Babaev authored
      The bug was in the code of the patch fixing bug 698882.
      With improper casting the method store_key_field::change_source_field
      was called for the elements of the array TABLE_REF::key_copy that
      were either of a different type or not allocated at all. This caused
      crashes in some queries. 
      a624f99e
  4. 16 Jan, 2011 1 commit
  5. 15 Jan, 2011 2 commits
    • Igor Babaev's avatar
      Fixed LP bug #698882. · 84a0c9b2
      Igor Babaev authored
      Made sure that the optimal fields are used by TABLE_REF objects
      when building index access keys to joined tables.
      Fixed a bug in the template function that sorts the elements of
      a list using the bubble sort algorithm. The bug caused poor
      performance of the function. Also added an optimization that
      skips comparison with the most heavy elements that has been 
      already properly placed in the list.
      Made the comparison of the fields belonging to the same Item_equal
      more granular: fields belonging to the same table are also ordered
      according to some rules.
      84a0c9b2
    • Igor Babaev's avatar
      Ported the fix for LP bug #702310 / bug #59493. · 0aebdc11
      Igor Babaev authored
      An assertion failure was triggered for a 6-way join query that used two
      join buffers.
      The failure happened because every call of JOIN_CACHE::join_matching_records
      saved and restored status of all tables that were accessed before the table
      join_tab. It must do it only for those of them that follow the last table 
      using a join buffer.
      0aebdc11
  6. 18 Oct, 2010 1 commit
  7. 13 Oct, 2010 1 commit
  8. 28 Sep, 2010 1 commit
    • Igor Babaev's avatar
      Fixed bug #52636. · 21b1b5f0
      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.
      21b1b5f0
  9. 15 Sep, 2010 1 commit
  10. 16 Feb, 2010 1 commit
  11. 03 Feb, 2010 3 commits
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · a800d18b
      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.
      a800d18b
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · 78103335
      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.
      78103335
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · 41894be0
      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.
      41894be0
  12. 29 Jan, 2010 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#49897: crash in ptr_compare when char(0) NOT NULL · 172af372
      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).
      172af372
  13. 15 Dec, 2009 3 commits
    • Ramil Kalimullin's avatar
      Fix for bug#49517: Inconsistent behavior while using · c5e6a11e
      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).
      c5e6a11e
    • Georgi Kodinov's avatar
      Bug#49489: Uninitialized cache led to a wrong result. · 838adcf2
      Georgi Kodinov authored
      Merge the fix from 5.1-bugteam to 5.1-main
      838adcf2
    • Sergey Petrunya's avatar
      Backport into MariaDB-5.2 the following: · 96e092dc
      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.
      96e092dc
  14. 09 Dec, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#49489: Uninitialized cache led to a wrong result. · 1285ecd4
      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.
      1285ecd4
  15. 04 Dec, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#49199: Optimizer handles incorrectly: · f5b51bc1
      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.
      f5b51bc1
  16. 25 Nov, 2009 2 commits
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · 6aeeacb8
      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.
      > ------------------------------------------------------------
      6aeeacb8
    • MySQL Build Team's avatar
      Backport into build-200911241145-5.1.40sp1 · df570b7c
      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.
      df570b7c
  17. 13 Nov, 2009 1 commit
    • Jorgen Loland's avatar
      Bug#48052: Valgrind warning - uninitialized value in · a120e969
      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.
      a120e969
  18. 09 Nov, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48458: simple query tries to allocate enormous amount of · 4519d5e4
      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.
      4519d5e4
  19. 30 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #48291 : crash with row() operator,select into @var, and · 9d96cd6d
      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.
      9d96cd6d
  20. 21 Oct, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug#47019: Assertion failed: 0, file .\rt_mbr.c, · 17ed6b9a
      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).
      17ed6b9a
  21. 26 Jun, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#45266: Uninitialized variable lead to an empty result. · 93bac51e
      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.
      93bac51e
  22. 17 Jun, 2009 1 commit
  23. 28 Apr, 2009 1 commit
    • Gleb Shchepa's avatar
      backport from 6.0: · def04705
      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.
      def04705
  24. 16 Mar, 2009 1 commit
    • Ramil Kalimullin's avatar
      Fix for bug #42957: no results from · 0fd7a359
      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.
      0fd7a359
  25. 28 Jan, 2009 1 commit
    • Alexey Kopytov's avatar
      Fix for bug #21205: Different number of digits for float/double/real in --ps-protocol · a0194637
      Alexey Kopytov authored
      Various parts of code used different 'precision' arguments for sprintf("%g") when converting
      floating point numbers to a string. This led to differences in results in some cases 
      depending on whether the text-based or prepared statements protocol is used for a query.
      
      Fixed by changing arguments to sprintf("%g") to always be 15 (DBL_DIG) so that results are
      consistent regardless of the protocol.
      
      This patch will be null-merged to 6.0 as the problem does not exists there (fixed by the
      patch for WL#2934).
      
      client/sql_string.cc:
        Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
      libmysql/libmysql.c:
        Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
      mysql-test/r/archive_gis.result:
        Fixed test results to take additional precision into account.
      mysql-test/r/func_group.result:
        Fixed test results to take additional precision into account.
      mysql-test/r/func_math.result:
        Fixed test results to take additional precision into account.
      mysql-test/r/func_str.result:
        Fixed test results to take additional precision into account.
      mysql-test/r/gis.result:
        Fixed test results to take additional precision into account.
      mysql-test/r/innodb_gis.result:
        Fixed test results to take additional precision into account.
      mysql-test/r/select.result:
        Fixed test results to take additional precision into account.
      mysql-test/r/sp.result:
        Fixed test results to take additional precision into account.
      mysql-test/r/type_float.result:
        Fixed test results to take additional precision into account.
      mysql-test/t/type_float.test:
        Fixed test results to take additional precision into account.
      sql/sql_string.cc:
        Use 15 (DBL_DIG) as a precision argument for sprintf(), as Field_double::val_str() does.
      a0194637
  26. 24 Dec, 2008 1 commit
    • Sergey Glukhov's avatar
      Bug#40953 SELECT query throws "ERROR 1062 (23000): Duplicate entry..." error · ce985aa3
      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
      ce985aa3
  27. 09 Dec, 2008 1 commit
    • Georgi Kodinov's avatar
      Bug #37936: ASSERT_COLUMN_MARKED_FOR_WRITE in Field_datetime::store , · bd865778
      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.
      bd865778
  28. 17 Feb, 2008 1 commit
    • unknown's avatar
      Bug #32942 now() - interval '7200' second NOT pre-calculated, causing "full table scan" · d6be1a9b
      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
      d6be1a9b
  29. 13 Feb, 2008 1 commit
    • unknown's avatar
      Fixed bug#33764: Wrong result with IN(), CONCAT() and implicit · 247efb9c
      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.
      247efb9c
  30. 12 Feb, 2008 1 commit
    • unknown's avatar
      Fix for Bug#32538: View definition picks up character set, · c1d0dd94
      unknown authored
      but not collation.
      
      The problem here was that text literals in a view were always
      dumped with character set introducer. That lead to loosing
      collation information.
      
      The fix is to dump character set introducer only if it was
      in the original query. That is now possible because there 
      is no problem any more of loss of character set of string
      literals in views -- after WL#4052 the view is dumped 
      in the original character set.
      
      
      mysql-test/r/case.result:
        Update result file.
      mysql-test/r/compress.result:
        Update result file.
      mysql-test/r/ctype_collate.result:
        Update result file.
      mysql-test/r/date_formats.result:
        Update result file.
      mysql-test/r/ddl_i18n_koi8r.result:
        Update result file.
      mysql-test/r/ddl_i18n_utf8.result:
        Update result file.
      mysql-test/r/fulltext.result:
        Update result file.
      mysql-test/r/func_crypt.result:
        Update result file.
      mysql-test/r/func_encrypt.result:
        Update result file.
      mysql-test/r/func_if.result:
        Update result file.
      mysql-test/r/func_in.result:
        Update result file.
      mysql-test/r/func_like.result:
        Update result file.
      mysql-test/r/func_regexp.result:
        Update result file.
      mysql-test/r/func_set.result:
        Update result file.
      mysql-test/r/func_str.result:
        Update result file.
      mysql-test/r/func_time.result:
        Update result file.
      mysql-test/r/gis.result:
        Update result file.
      mysql-test/r/group_min_max.result:
        Update result file.
      mysql-test/r/mysqldump.result:
        Update result file.
      mysql-test/r/negation_elimination.result:
        Update result file.
      mysql-test/r/null.result:
        Update result file.
      mysql-test/r/select.result:
        Update result file.
      mysql-test/r/show_check.result:
        Update result file.
      mysql-test/r/sp-code.result:
        Update result file.
      mysql-test/r/ssl.result:
        Update result file.
      mysql-test/r/ssl_compress.result:
        Update result file.
      mysql-test/r/subselect.result:
        Update result file.
      mysql-test/r/temp_table.result:
        Update result file.
      mysql-test/r/type_blob.result:
        Update result file.
      mysql-test/r/view.result:
        Update result file.
      mysql-test/suite/binlog/r/binlog_stm_blackhole.result:
        Update result file.
      mysql-test/suite/rpl/r/rpl_get_lock.result:
        Update result file.
      mysql-test/suite/rpl/r/rpl_master_pos_wait.result:
        Update result file.
      mysql-test/t/view.test:
        Add a test case for Bug#32538.
      sql/item.cc:
        Do not dump character set introducer if it was not specified
        explicitly in the original query.
      sql/item.h:
        Add 'cs_specified' property to Item_string.
      sql/sql_yacc.yy:
        Set Item_string::cs_specified property to TRUE
        when character set introducer is explicitly specified.
      c1d0dd94
  31. 17 Nov, 2007 1 commit
    • unknown's avatar
      Fixed bug #32335. · 99054db6
      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.
      99054db6
  32. 10 Nov, 2007 1 commit
    • unknown's avatar
      Bug#31800: Date comparison fails with timezone and slashes for greater than comparison · ac3ef6c7
      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.
      ac3ef6c7
  33. 07 Nov, 2007 2 commits
    • unknown's avatar
      Fix for bug #32103: optimizer crash when join on int and mediumint with · 0a7a55d1
      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().
      0a7a55d1
    • unknown's avatar
      Fix for bug #30666: Incorrect order when using range conditions on 2 · f6686659
      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.
      f6686659