1. 10 Jul, 2006 4 commits
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · 7bea031d
      unknown authored
      into  moonbone.local:/work/allany-4.1-mysql
      
      
      7bea031d
    • unknown's avatar
      Fixed bug#16302: Quantified subquery without any tables gives wrong results · ad88eabd
      unknown authored
      The ALL/ANY subqueries are the subject of MIN/MAX optimization. The matter
      of this optimization is to embed MIN() or MAX() function into the subquery
      in order to get only one row by which we can tell whether the expression
      with ALL/ANY subquery is true or false.
      But when it is applied to a subquery like 'select a_constant' the reported bug
      occurs. As no tables are specified in the subquery the do_select() function 
      isn't called for the optimized subquery and thus no values have been added 
      to a MIN()/MAX() function and it returns NULL instead of a_constant.
      This leads to a wrong query result.
      
      For the subquery like 'select a_constant' there is no reason to apply
      MIN/MAX optimization because the subquery anyway will return at most one row.
      Thus the Item_maxmin_subselect class is more appropriate for handling such
      subqueries.
      
      The Item_in_subselect::single_value_transformer() function now checks
      whether tables are specified for the subquery. If no then this subselect is
      handled like a UNION using an Item_maxmin_subselect object.
      
      
      mysql-test/t/subselect.test:
        Added test case for bug#16302: Quantified subquery without any tables gives wrong results
      mysql-test/r/subselect.result:
        Added test case for bug#16302: Quantified subquery without any tables gives wrong results
      sql/item_subselect.cc:
        Fixed bug#16302: Quantified subquery without any tables gives wrong results
         
        The Item_in_subselect::single_value_transformer() function now checks
        whether tables are specified for the subquery. If no then this subselect is
        handled like a UNION using an Item_maxmin_subselect object.
      ad88eabd
    • unknown's avatar
      Merge rakia:mysql/4.1/B14553 · ca1e4aab
      unknown authored
      into  macbook.gmz:/Users/kgeorge/mysql/work/B14553-4.1-opt
      
      
      sql/sql_class.cc:
        SCCS merged
      sql/sql_select.cc:
        SCCS merged
      ca1e4aab
    • unknown's avatar
      BUG#14553: NULL in WHERE resets LAST_INSERT_ID · 0806d9a8
      unknown authored
      To make MySQL compatible with some ODBC applications, you can find
      the AUTO_INCREMENT value for the last inserted row with the following query:
       SELECT * FROM tbl_name WHERE auto_col IS NULL.
      This is done with a special code that replaces 'auto_col IS NULL' with
      'auto_col = LAST_INSERT_ID'.
      However this also resets the LAST_INSERT_ID to 0 as it uses it for a flag
      so as to ensure that only the first SELECT ... WHERE auto_col IS NULL
      after an INSERT has this special behaviour.
      In order to avoid resetting the LAST_INSERT_ID a special flag is introduced
      in the THD class. This flag is used to restrict the second and subsequent
      SELECTs instead of LAST_INSERT_ID.
      
      
      mysql-test/r/odbc.result:
        test suite for the bug
      mysql-test/r/rpl_insert_id.result:
        test for the fix in replication
      mysql-test/t/odbc.test:
        test suite for the bug
      mysql-test/t/rpl_insert_id.test:
        test for the fix in replication
      sql/sql_class.cc:
        initialize the flag
      sql/sql_class.h:
        flag's declaration and set code when setting the last_insert_id
      sql/sql_select.cc:
        the special flag is used instead of last_insert_id
      0806d9a8
  2. 06 Jul, 2006 2 commits
    • unknown's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · 8cb368bc
      unknown authored
      into  olga.mysql.com:/home/igor/mysql-4.1-opt
      
      
      8cb368bc
    • unknown's avatar
      Fixed bug #18243. · cf7627bc
      unknown authored
      The implementation of the method Item_func_reverse::val_str
      for the REVERSE function modified the argument of the function.
      This led to wrong results for expressions that contained
      REVERSE(ref) if ref occurred somewhere else in the expressions.
      
      
      mysql-test/r/func_str.result:
        Added a test case for bug #18243.
      mysql-test/t/func_str.test:
        Added a test case for bug #18243.
      sql/item_strfunc.cc:
        Fixed bug #18243.
        The implementation of the method Item_func_reverse::val_str
        for the REVERSE function modified the argument of the function.
        This led to wrong results for expressions that contained
        REVERSE(ref) if ref occurred somewhere else in the expressions.
        
        The implementation of Item_func_reverse::val_str has been changed
        to make the argument intact.
      sql/item_strfunc.h:
        Fixed bug #18243.
        Added tmp_value to the Item_func_reverse class to store
        the result of the function. It erroneously replaced the 
        argument before this fix.
      cf7627bc
  3. 04 Jul, 2006 1 commit
  4. 29 Jun, 2006 5 commits
  5. 28 Jun, 2006 3 commits
  6. 27 Jun, 2006 5 commits
    • unknown's avatar
      BUG#1662 - ALTER TABLE LIKE ignores DATA/INDEX DIRECTPORY · f4a07612
      unknown authored
      Produce a warning if DATA/INDEX DIRECTORY is specified in
      ALTER TABLE statement.
      
      Ignoring of these options is documented in the symbolic links
      section of the manual.
      
      
      mysql-test/r/symlink.result:
        Modified test result according to fix for BUG#1662.
      sql/sql_parse.cc:
        Produce a warning if DATA/INDEX DIRECTORY is specified in
        ALTER TABLE statement.
      f4a07612
    • unknown's avatar
      Merge mysql.com:/home/kgeorge/mysql/4.1/teamclean · 2eb16be0
      unknown authored
      into  mysql.com:/home/kgeorge/mysql/4.1/B16458
      
      
      2eb16be0
    • unknown's avatar
      Dec. 31st, 9999 is still a valid date, only starting with Jan 1st 10000 things... · 82d127b5
      unknown authored
      Dec. 31st, 9999 is still a valid date, only starting with Jan 1st 10000 things become invalid (Bug #12356)
      
      
      mysql-test/r/func_sapdb.result:
        test cases for date range edge cases added
      mysql-test/r/func_time.result:
        test cases for date range edge cases added
      mysql-test/t/func_sapdb.test:
        test cases for date range edge cases added
      mysql-test/t/func_time.test:
        test cases for date range edge cases added
      82d127b5
    • unknown's avatar
      Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error · 4b36c1d8
      unknown authored
      'SELECT DISTINCT a,b FROM t1' should not use temp table if there is unique 
      index (or primary key) on a.
      There are a number of other similar cases that can be calculated without the
      use of a temp table : multi-part unique indexes, primary keys or using GROUP BY 
      instead of DISTINCT.
      When a GROUP BY/DISTINCT clause contains all key parts of a unique
      index, then it is guaranteed that the fields of the clause will be
      unique, therefore we can optimize away GROUP BY/DISTINCT altogether.
      This optimization has two effects:
      * there is no need to create a temporary table to compute the
         GROUP/DISTINCT operation (or the temporary table will be smaller if only GROUP 
         is removed and DISTINCT stays or if DISTINCT is removed and GROUP BY stays)
      * this causes the statement in effect to become updatable in Connector/Java
      because the result set columns will be direct reference to the primary key of 
      the table (instead to the temporary table that it currently references). 
      
      Implemented a check that will optimize away GROUP BY/DISTINCT for queries like 
      the above.
      Currently it will work only for single non-constant table in the FROM clause.
      
      
      mysql-test/r/distinct.result:
        Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
          - test case
      mysql-test/t/distinct.test:
        Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
          - test case
      sql/sql_select.cc:
        Bug #16458: Simple SELECT FOR UPDATE causes "Result Set not updatable" error
          - disable GROUP BY if contains the fields of a unique index.
      4b36c1d8
    • unknown's avatar
      Merge abotchkov@bk-internal.mysql.com:/home/bk/mysql-4.1 · 79952ec0
      unknown authored
      into mysql.com:/home/hf/work/mysql-4.1.clean
      
      
      79952ec0
  7. 26 Jun, 2006 4 commits
  8. 23 Jun, 2006 2 commits
    • unknown's avatar
      Bug#11228: DESC shows arbitrary column as "PRI" · 89e41595
      unknown authored
        An UNIQUE KEY consisting of NOT NULL columns
        was displayed as PRIMARY KEY in "DESC t1".
        According to the code, that was intentional
        behaviour for some reasons unknown to me.
        This code was written before bitkeeper time,
        so I cannot check who and why made this.
        After discussing on dev-public, a decision
        was made to remove this code
      
      
      mysql-test/r/key.result:
        Adding test case.
      mysql-test/t/key.test:
        Adding test case.
      sql/table.cc:
        Removing old wrong code
      89e41595
    • unknown's avatar
      Added a test case for bug #18359. · d62551af
      unknown authored
      This was another manifestation of the problems fixed in the
      patch for bug 16674.
      Wrong calculation of length of the search prefix in the pattern
      string led here to a wrong result set for a query in 4.1. 
      The bug could be demonstrated for any multi-byte character set. 
      
      
      mysql-test/r/ctype_utf8.result:
        Added a test case for bug #18359.
      mysql-test/t/ctype_utf8.test:
        Added a test case for bug #18359.
      d62551af
  9. 22 Jun, 2006 4 commits
    • unknown's avatar
      Fixed bug #20076. · e8adb499
      unknown authored
      Server crashed in some cases when a query required a MIN/MAX
      agrregation for a 'ucs2' field. 
      In these cases  the aggregation caused calls of the function
      update_tmptable_sum_func that indirectly invoked 
      the method Item_sum_hybrid::min_max_update_str_field() 
      containing a call to strip_sp for a ucs2 character set.
      The latter led directly to the crash as it used my_isspace
      undefined for the ucs2 character set.
      Actually the call of strip_sp is not needed at all in this
      situation and has been removed by the fix.
      
      
      mysql-test/r/ctype_ucs.result:
        Added a test case for bug #20076.
      mysql-test/t/ctype_ucs.test:
        Added a test case for bug #20076.
      e8adb499
    • unknown's avatar
      mysql.spec.sh: · 92ad3d5b
      unknown authored
        Disable the simplistic auto dependency scan for test/bench (bug#20078)
      
      
      support-files/mysql.spec.sh:
        Disable the simplistic auto dependency scan for test/bench (bug#20078)
      92ad3d5b
    • unknown's avatar
      bug #10166 (Signed byte values cause data to be padded) · 9a4b76ed
      unknown authored
      The AsBinary function returns VARCHAR data type with binary collation.
      It can cause problem for clients that treat that kind of data as
      different from BLOB type.
      So now AsBinary returns BLOB.
      
      
      mysql-test/r/gis.result:
        result fixed
      mysql-test/t/gis.test:
        test case added
      sql/item_geofunc.h:
        Now we return MYSQL_TYPE_BLOB for asBinary function
      9a4b76ed
    • unknown's avatar
      Modified the test case for bug 16674 to have the same · af3c7663
      unknown authored
      execution plans in 4.1 and 5.0.
      
      
      af3c7663
  10. 21 Jun, 2006 9 commits
    • unknown's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · 6a631065
      unknown authored
      into  rurik.mysql.com:/home/igor/mysql-4.1-opt
      
      
      mysql-test/r/ctype_utf8.result:
        SCCS merged
      mysql-test/t/ctype_utf8.test:
        SCCS merged
      6a631065
    • unknown's avatar
      Merge epotemkin@bk-internal.mysql.com:/home/bk/mysql-4.1 · d5797063
      unknown authored
      into moonbone.local:/work/tmp_merge-4.1-opt-mysql
      
      
      d5797063
    • unknown's avatar
      Fixed bug #14896. · 822e8866
      unknown authored
      This bug in Field_string::cmp resulted in a wrong comparison 
      with keys in partial indexes over multi-byte character fields.
      Given field a is declared as a varchar(16) collate utf8_unicode_ci
      INDEX(a(4)) gives us an example of such an index.
        
      Wrong key comparisons could lead to wrong result sets if 
      the selected query execution plan used a range scan by 
      a partial index over a utf8 character field.
      This also caused wrong results in many other cases.
      
      
      mysql-test/t/ctype_utf8.test:
        Added test cases for bug #14896.
      mysql-test/r/ctype_utf8.result:
        Added test cases for bug #14896.
      sql/field.cc:
        Fixed bug #14896.
        This bug in Field_string::cmp resulted in a wrong comparison 
        with keys in partial indexes over multi-byte character fields.
        Given field a is declared as a varchar(16) collate utf8_unicode_ci
        INDEX(a(4)) gives us an example of such an index.
             
        Wrong key comparisons could lead to wrong result sets if 
        the selected query execution plan used a range scan by 
        a partial index over a utf8 character field.
        This also caused wrong results in many other cases.
      822e8866
    • unknown's avatar
      Merge svojtovich@bk-internal.mysql.com:/home/bk/mysql-4.1 · 630a1ee4
      unknown authored
      into  may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1
      
      
      630a1ee4
    • unknown's avatar
      added missing MYSQLTEST_VARDIR declaration · fa83f8ba
      unknown authored
      fa83f8ba
    • unknown's avatar
      Merge april:devel/BitKeeper/mysql-4.1 · bf76f070
      unknown authored
      into  may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1
      
      
      sql/opt_sum.cc:
        Auto merged
      mysql-test/r/myisam.result:
        SCCS merged
      mysql-test/t/myisam.test:
        SCCS merged
      bf76f070
    • unknown's avatar
      BUG#20357 - Got error 124 from storage engine using MIN and MAX · 5c0cdea6
      unknown authored
                  functions in queries
      
      Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE)
      results in error 124 (wrong index) from storage engine.
      
      The problem was that optimizer use disabled index to optimize
      MAX()/MIN(). Normally it must skip disabled index and perform
      table scan.
      
      This patch skips disabled indexes for min/max optimization.
      
      
      mysql-test/r/myisam.result:
        Test case for BUG#20357.
      mysql-test/t/myisam.test:
        Test case for BUG#20357.
      sql/opt_sum.cc:
        Skip disabled/ignored indexes for min/max optimization.
      5c0cdea6
    • unknown's avatar
      Merge ibabaev@bk-internal.mysql.com:/home/bk/mysql-4.1-opt · 8516546c
      unknown authored
      into  rurik.mysql.com:/home/igor/mysql-4.1-opt
      
      
      8516546c
    • unknown's avatar
      Fixed bug #16674. · 69977fa5
      unknown authored
      The length of the prefix of the pattern string in the LIKE predicate that 
      determined the index range to be scanned was calculated incorrectly for
      multi-byte character sets. 
      As a result of this in 4. 1 the the scanned range was wider then necessary
      if the prefix contained not only one-byte characters.  
      In 5.0 additionally it caused missing some rows from the result set.
      
      
      mysql-test/r/ctype_utf8.result:
        Added test cases for bug #16674.
      mysql-test/t/ctype_utf8.test:
        Added test cases for bug #16674.
      strings/ctype-mb.c:
        Fixed bug #16674.
        The length of the prefix of the pattern string in the LIKE predicate that 
        determined the index range to be scanned was calculated incorrectly for
        multi-byte character sets. 
        As a result of this in 4. 1 the the scanned range was wider then necessary
        if the prefix contained not only one-byte characters.  
        In 5.0 additionally it caused missing some rows from the result set.
            
        The function my_like_range_mb was fixed to calculate the length of
        the prefix in a pattern string correctly in all cases.
      69977fa5
  11. 20 Jun, 2006 1 commit