An error occurred fetching the project authors.
  1. 24 May, 2006 1 commit
    • unknown's avatar
      sql_select.cc: · 2baef06f
      unknown authored
        After merge fix
      
      
      sql/sql_select.cc:
        After merge fix
      2baef06f
  2. 23 May, 2006 1 commit
    • unknown's avatar
      Fix for bug#17626 CREATE TABLE ... SELECT failure with TRADITIONAL SQL mode · 798e1498
      unknown authored
      transfer NO_DEFAULT_VALUE_FLAG flag to new field
      
      
      mysql-test/r/strict.result:
        Fix for bug#17626 CREATE TABLE ... SELECT failure with TRADITIONAL SQL mode
        test case
      mysql-test/r/type_ranges.result:
        Fix for bug#17626 CREATE TABLE ... SELECT failure with TRADITIONAL SQL mode
        result fix
      mysql-test/t/strict.test:
        Fix for bug#17626 CREATE TABLE ... SELECT failure with TRADITIONAL SQL mode
        test case
      798e1498
  3. 22 May, 2006 1 commit
    • unknown's avatar
      Post-review fixes for bug #19089 · 9f628bb2
      unknown authored
      mysql-test/r/view.result:
        Post-review fixes.
      sql/field.cc:
        Post-review fixes.
      sql/field.h:
        Post-review fixes.
      sql/sql_select.cc:
        Post-review fixes.
      9f628bb2
  4. 21 May, 2006 1 commit
    • unknown's avatar
      Fixed bug #19089. · 765a7d69
      unknown authored
      When a CREATE TABLE command created a table from a materialized
      view id does not inherit default values from the underlying table.
      Moreover the temporary table used for the view materialization
      does not inherit those default values.
      In the case when the underlying table contained ENUM fields it caused
      misleading error messages. In other cases the created table contained
      wrong default values.
      The code was modified to ensure inheritance of default values for
      materialized views.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #19089.
      mysql-test/t/view.test:
        Added a test case for bug #19089.
      sql/field.cc:
        Fixed bug ##19089.
        Added field dflt_field to the class Field.
        This field is set for temp table fields that inherits
        default values of items from which they are created.
      sql/field.h:
        Fixed bug ##19089.
        Added field dflt_field to the class Field.
        This field is set for temp table fields that inherits
        default values of items from which they are created.
      sql/sql_select.cc:
        Fixed bug #19089.
        When a CREATE TABLE command created a table from a materialized
        view id does not inherit default values from the underlying table.
        Moreover the temporary table used for the view materialization
        does not inherit those default values.
        The code was modified to ensure inheritance of default values for
        materialized views.
      765a7d69
  5. 10 May, 2006 1 commit
    • unknown's avatar
      BUG#17379 Wrong reuse of E(#rows(range)) as E(#rows(ref(const))): · 7c63a144
      unknown authored
      Re-work best_access_path() and find_best() to reuse E(#rows(range access)) as
      E(#rows(ref[_or_null](const) access) only when it is appropriate.
      [This is the final cumulative patch]
      
      
      mysql-test/r/select.result:
        BUG#17379: Testcase
      mysql-test/r/subselect.result:
        BUG#17379: Updated test results
      mysql-test/t/select.test:
        BUG#17379: Testcase
      sql/opt_range.cc:
        BUG#17379: Wrong reuse of E(#rows(range)) as E(#rows(ref(const))):
        Make range optimizer together with TABLE::quick_* also return TABLE::quick_n_ranges
      sql/sql_select.cc:
        BUG#17379: Wrong reuse of E(#rows(range)) as E(#rows(ref(const))):
        Re-work best_access_path() to reuse E(#rows(range access)) as
        E(#rows(ref[_or_null](const) access) only when it is appropriate.
      sql/table.h:
        BUG#17379: Wrong reuse of E(#rows(range)) as E(#rows(ref(const))):
        Make range optimizer together with TABLE::quick_* also return TABLE::quick_n_ranges
      7c63a144
  6. 09 May, 2006 1 commit
    • unknown's avatar
      BUG#18068: SELECT DISTINCT (with duplicates and covering index) · 52ae8e1e
      unknown authored
      When converting DISTINCT to GROUP BY where the columns are from the covering
      index and they are quoted twice in the SELECT list the optimizer is creating
      improper processing sequence. This is because of the fact that the columns
      of the covering index are not recognized as such and treated as non-index
      columns.
      
      Generally speaking duplicate columns can safely be removed from the GROUP
      BY/DISTINCT list because this will not add or remove new rows in the
      resulting set. Duplicates can be removed even if they are not consecutive
      (as is the case for ORDER BY, where the duplicate columns can be removed
      only if they are consecutive).
      
      So we can safely transform "SELECT DISTINCT a,a FROM ... ORDER BY a" to
      "SELECT a,a FROM ... GROUP BY a ORDER BY a" instead of 
      "SELECT a,a FROM .. GROUP BY a,a ORDER BY a". We can even transform 
      "SELECT DISTINCT a,b,a FROM ... ORDER BY a,b" to
      "SELECT a,b,a FROM ... GROUP BY a,b ORDER BY a,b".
      
      The fix to this bug consists of checking for duplicate columns in the SELECT
      list when constructing the GROUP BY list in transforming DISTINCT to GROUP
      BY and skipping the ones that are already in.
      
      
      mysql-test/r/distinct.result:
        test case for the bug without loose index scan
      mysql-test/r/group_min_max.result:
        test case for the bug
      mysql-test/t/distinct.test:
        test case for the bug without loose index scan
      mysql-test/t/group_min_max.test:
        test case for the bug
      sql/sql_select.cc:
        duplicates check and removal
      52ae8e1e
  7. 07 May, 2006 3 commits
    • unknown's avatar
    • unknown's avatar
      Refactoring: Factor out common code from find_best() and best_access_path(): make · ad8d6c9e
      unknown authored
      find_best() call best_access_path().
      
      ad8d6c9e
    • unknown's avatar
      Fixed bug #14927. · 39c73589
      unknown authored
      A query with a group by and having clauses could return a wrong
      result set if the having condition contained a constant conjunct 
      evaluated to FALSE.
      It happened because the pushdown condition for table with
      grouping columns lost its constant conjuncts.
      Pushdown conditions are always built by the function make_cond_for_table
      that ignores constant conjuncts. This is apparently not correct when
      constant false conjuncts are present.
      
      
      
      mysql-test/r/having.result:
        Added a test case for bug #14927.
      mysql-test/t/having.test:
        Added a test case for bug #14927.
      sql/sql_lex.cc:
        Fixed bug #14927.
        Initialized fields for having conditions in  st_select_lex::init_query().
      sql/sql_lex.h:
        Fixed bug #14927.
        Added a field to restore having condititions for execution in SP and PS.
      sql/sql_prepare.cc:
        Fixed bug #14927.
        Added code to restore havinf conditions for execution in SP and PS.
      sql/sql_select.cc:
        Fixed bug #14927.
        Performed evaluation of constant expressions in having clauses.
        If the having condition contains a constant conjunct that is always false
        an empty result set is returned after the optimization phase.
        In this case the corresponding EXPLAIN command now returns 
        "Impossible HAVING" in the last column.
      39c73589
  8. 06 May, 2006 1 commit
    • unknown's avatar
      BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions · 4427076e
      unknown authored
      The bug was as follows: When merge_key_fields() encounters "t.key=X OR t.key=Y" it will 
      try to join them into ref_or_null access via "t.key=X OR NULL". In order to make this 
      inference it checks if Y<=>NULL, ignoring the fact that value of Y may be not yet known.
      
      The fix is that the check if Y<=>NULL is made only if value of Y is known (i.e. it is a
      constant).
      TODO: When merging to 5.0, replace used_tables() with const_item() everywhere in merge_key_fields().
      
      
      mysql-test/r/innodb_mysql.result:
        Testcase for BUG16798
      mysql-test/t/innodb_mysql.test:
        Testcase for BUG16798
      sql/sql_select.cc:
        BUG#16798: Inapplicable ref_or_null query plan and bad query result on random occasions 
        In merge_key_fields() don't call val->is_null() if the value of val is not known.
      4427076e
  9. 03 May, 2006 1 commit
    • unknown's avatar
      Fixed bug #14292: performance degradation for a benchmark query. · 80ab59b4
      unknown authored
      This performance degradation was due to the fact that some
      cost evaluation code added into 4.1 in the function find_best was
      not merged into the code of the function best_access_path added
      together with other code for greedy optimizer.
      Added a parameter to the function print_plan. The parameter contains
      accumulated cost for a given partial join.
       
      The patch does not include a special test case since this performance
      degradation is hard to reproduse with a simple example.
      
      TODO: make the function find_best use the function best_access_path
      in order to remove duplication of code which might result in incomplete
      merges in the future.
      
      
      mysql-test/r/delete.result:
        Fixed bug #14292: performance degradation for a benchmark query.
        Adjusted test results.
      mysql-test/r/subselect.result:
        Fixed bug #14292: performance degradation for a benchmark query.
        Adjusted test results.
      sql/mysql_priv.h:
        Fixed bug #14292: performance degradation for a benchmark query.
        Added a parameter to the function print_plan. The parameter contains
        accumulated cost for a given partial join.
      sql/sql_select.cc:
        Fixed bug #14292: performance degradation for a benchmark query.
        This performance degradation was due to the fact that some
        cost evaluation code added into 4.1 in the function find_best was
        not merged into the code of the function best_access_path added
        together with other code for greedy optimizer.
      sql/sql_test.cc:
        Fixed bug #14292: performance degradation for a benchmark query.
        Added a parameter to the function print_plan. The parameter contains
        accumulated cost for a given partial join.
      80ab59b4
  10. 21 Apr, 2006 1 commit
    • unknown's avatar
      Fixed bug #18767. · 3dd2f261
      unknown authored
      The bug caused wrong result sets for union constructs of the form
      (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2.
      For such queries order lists were concatenated and limit clause was
      completely neglected. 
      
      
      mysql-test/r/order_by.result:
        Added a test case for bug #18767.
      mysql-test/t/order_by.test:
        Added a test case for bug #18767.
      sql/sql_lex.h:
        Fixed bug #18767.
        Placed the code the created a fake SELECT_LEX into a separate function.
      sql/sql_parse.cc:
        Fixed bug #18767.
        Placed the code the created a fake SELECT_LEX into a separate function.
      sql/sql_select.cc:
        Fixed bug #18767.
        Changed the condition on which a SELECT is treated as part of a UNION.
        The SELECT in 
        (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 
        now is handled in the same way as the first SELECT in a UNION
        sequence.
      sql/sql_union.cc:
        Fixed bug #18767.
        Changed the condition at which a SELECT is treated as part of a UNION.
        The SELECT in 
        (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 
        now is handled in the same way as the first SELECT in a UNION
        sequence.
      sql/sql_yacc.yy:
        Fixed bug #18767.
        Changed the condition at which a SELECT is treated as part of a UNION.
        The SELECT in 
        (SELECT ... ORDER BY order_list1 [LIMIT n]) ORDER BY order_list2 
        now is handled in the same way as the first SELECT in a UNION
        sequence. In the same way is handled the SELECT in
        (SELECT ... LIMIT n) ORDER BY order list.
        Yet if there is neither ORDER BY nor LIMIT in the single-select
        union construct
        (SELECT ...) ORDER BY order_list
        then it is still handled as simple select with an order clause.
      3dd2f261
  11. 20 Apr, 2006 2 commits
    • unknown's avatar
      Fixed bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode. · ba39dcf6
      unknown authored
      The SQL standard doesn't allow to use in HAVING clause fields that are not 
      present in GROUP BY clause and not under any aggregate function in the HAVING
      clause. However, mysql allows using such fields. This extension assume that 
      the non-grouping fields will have the same group-wise values. Otherwise, the 
      result will be unpredictable. This extension allowed in strict 
      MODE_ONLY_FULL_GROUP_BY sql mode results in misunderstanding of HAVING 
      capabilities.
      
      The new error message ER_NON_GROUPING_FIELD_USED message is added. It says
      "non-grouping field '%-.64s' is used in %-.64s clause". This message is
      supposed to be used for reporting errors when some field is not found in the
      GROUP BY clause but have to be present there. Use cases for this message are 
      this bug and when a field is present in a SELECT item list not under any 
      aggregate function and there is GROUP BY clause present which doesn't mention 
      that field. It renders the ER_WRONG_FIELD_WITH_GROUP error message obsolete as
      being more descriptive.
      The resolve_ref_in_select_and_group() function now reports the 
      ER_NON_GROUPING_FIELD_FOUND error if the strict mode is set and the field for 
      HAVING clause is found in the SELECT item list only.
      
      
      
      sql/share/errmsg.txt:
        Added the new ER_NON_GROUPING_FIELD_USED error message for the bug#14169.
      mysql-test/t/having.test:
        Added test case for the bug#18739:  non-standard HAVING extension was allowed in strict ANSI sql mode.
      mysql-test/r/having.result:
        Added test case for the bug#18739:  non-standard HAVING extension was allowed in strict ANSI sql mode.
      sql/sql_select.cc:
        Added TODO comment to change the ER_WRONG_FIELD_WITH_GROUP to more detailed ER_NON_GROUPING_FIELD_USED message.
      sql/item.cc:
        Fixed bug#18739: non-standard HAVING extension was allowed in strict ANSI sql mode.
        The resolve_ref_in_select_and_group() function now reports the
        ER_NON_GROUPING_FIELD_FOUND error if the strict MODE_ONLY_FULL_GROUP_BY mode
        is set and the field for HAVING clause is found in the SELECT item list only.
      ba39dcf6
    • unknown's avatar
      Post merge fix · 5451e0fe
      unknown authored
      5451e0fe
  12. 12 Apr, 2006 1 commit
    • unknown's avatar
      Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was · 9c2d7216
      unknown authored
      used
      
      In a simple queries a result of the GROUP_CONCAT() function was always of 
      varchar type.
      But if length of GROUP_CONCAT() result is greater than 512 chars and temporary
      table is used during select then the result is converted to blob, due to
      policy to not to store fields longer than 512 chars in tmp table as varchar
      fields.
      
      In order to provide consistent behaviour, result of GROUP_CONCAT() now
      will always be converted to blob if it is longer than 512 chars.
      Item_func_group_concat::field_type() is modified accordingly.
      
      
      mysql-test/t/func_gconcat.test:
        Added test case for bug#14169: type of group_concat() result changed to blob if tmp_table was used
      mysql-test/r/func_gconcat.result:
        Added test case for bug#14169: type of group_concat() result changed to blob if tmp_table was used
      sql/unireg.h:
        Added the CONVERT_IF_BIGGER_TO_BLOB constant
      sql/sql_select.cc:
        Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
        The unnamed constant 255 in the create_tmp_field() and create_tmp_field_from_item() functions now defined as the CONVERT_IF_BIGGER_TO_BLOB constant.
        The create_tmp_field() function now converts the Item_sum string result to a blob field based on its char length.
      sql/item_sum.h:
        Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
        To the Item_func_group_concat calls added the member function field_type() which returns the BLOB or VAR_STRING type based on the items length.
      sql/item_func.cc:
        Fixed bug#14169: type of group_concat() result changed to blob if tmp_table was used
        In the Item_func::tmp_table_field() function the unnamed constant 255 is changed to the CONVERT_IF_BIGGER_TO_BLOB constant.
        The Item_func::tmp_table_field() function now measures the result length in chars rather than bytes when converting string result to a blob.
      9c2d7216
  13. 04 Apr, 2006 1 commit
  14. 01 Apr, 2006 1 commit
    • unknown's avatar
      Fixed bug #16504. · 62302ad0
      unknown authored
      Multiple equalities were not adjusted after reading constant tables.
      It resulted in neglecting good index based methods that could be
      used to access of other tables.
      
      
      mysql-test/r/having.result:
        Adjusted a test case results after fix for bug #16504.
      mysql-test/r/select.result:
        Added a test case for bug #16504.
      mysql-test/r/subselect.result:
        Adjusted a test case results after fix for bug #16504.
      mysql-test/r/varbinary.result:
        Adjusted a test case results after fix for bug #16504.
      mysql-test/t/select.test:
        Added a test case for bug #16504.
      sql/item.cc:
        Fixed bug #16504.
        An Item_equal object may contain only a constant member.
        It may happen after reading constant tables.
      sql/item_cmpfunc.cc:
        Fixed bug #16504.
        Added method Item_equal::check_const that check appearance of new 
        constant items in a multiple equality.
      sql/item_cmpfunc.h:
        Fixed bug #16504.
        Added method Item_equal::check_const that check appearance of new 
        constant items in a multiple equality.
      sql/sql_select.cc:
        Fixed bug #16504.
        Adjusted multiple equalities after reading constant tables.
        Fixed a few typo in comments.
      62302ad0
  15. 30 Mar, 2006 2 commits
    • unknown's avatar
      item_sum.cc, sql_select.cc: · bcad85f7
      unknown authored
        After merge fix for bug#15560
      item_sum.h:
         After merge fix for bug#15560
      
      
      sql/sql_select.cc:
        After merge fix for bug#15560
      sql/item_sum.h:
         After merge fix for bug#15560
      sql/item_sum.cc:
        After merge fix for bug#15560
      bcad85f7
    • unknown's avatar
      Fixed bug #18279: crash in the cases when on conditions are moved · 72b1b71c
      unknown authored
      out of a nested join to the on conditions for the nest.
      The bug happened due to:
      1. The function simplify_joins could change on expressions for nested joins.
         Yet modified on expressions were not saved in prep_on_expr.
      2. On expressions were not restored for nested joins in 
         reinit_stmt_before_use.
      
      
      mysql-test/r/join_nested.result:
        Added a test case for bug #18279.
      mysql-test/t/join_nested.test:
        Added a test case for bug #18279.
      sql/sql_prepare.cc:
        Fixed bug #18279.
        On expressions were not restored for nested joins in 
        reinit_stmt_before_use.
      sql/sql_select.cc:
        Fixed bug #18279.
        The function simplify_joins could change on expressions for nested joins.
        Yet modified on expressions were not saved in prep_on_expr.
      72b1b71c
  16. 29 Mar, 2006 1 commit
    • unknown's avatar
      Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries · 8d5277a7
      unknown authored
      The GROUP_CONCAT uses its own temporary table. When ROLLUP is present
      it creates the second copy of Item_func_group_concat. This copy receives the
      same list of arguments that original group_concat does. When the copy is
      set up the result_fields of functions from the argument list are reset to the
      temporary table of this copy.
      As a result of this action data from functions flow directly to the ROLLUP copy
      and the original group_concat functions shows wrong result.
      Since queries with COUNT(DISTINCT ...) use temporary tables to store
      the results the COUNT function they are also affected by this bug.
      
      The idea of the fix is to copy content of the result_field for the function
      under GROUP_CONCAT/COUNT from  the first temporary table to the second one,
      rather than setting result_field to point to the second temporary table.
      To achieve this goal force_copy_fields flag is added to Item_func_group_concat
      and Item_sum_count_distinct classes. This flag is initialized to 0 and set to 1
      into the make_unique() member function of both classes.
      To the TMP_TABLE_PARAM structure is modified to include the similar flag as
      well.
      The create_tmp_table() function passes that flag to create_tmp_field().
      When the flag is set the create_tmp_field() function will set result_field
      as a source field and will not reset that result field to newly created 
      field for Item_func_result_field and its descendants. Due to this there
      will be created copy func to copy data from old result_field to newly 
      created field.
      
      
      mysql-test/t/func_gconcat.test:
        Added test for bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
      mysql-test/r/func_gconcat.result:
        Added test for bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
      sql/sql_table.cc:
        Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
        Added 0 as a last parameter to create_tmp_field()  to force old behaviour.
      sql/sql_select.cc:
        Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
        
        Added the flag 'make_copy_field' to create_tmp_field(), so that for Item_result_field descendants create_tmp_field() sets the item's result field as a source field and deny resetting that result field to a new value.
      sql/sql_class.h:
        Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
        Added the flag 'force_copy_fields' to the structure TMP_TABLE_PARAM in order to make create_tmp_field() force the creation of 'copy_field' objects.
      sql/mysql_priv.h:
        Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
        Added the bool parameter 'make_copy_field' to create_tmp_field().
      sql/item_sum.cc:
        Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
        Added initialization of the force_copy_fields flag and passing it to create_tmp_table() through TMP_TBLE_PARAM in the Item_func_group_concat and Item_sum_count_distinct member functions.
      sql/item_sum.h:
        Fixed bug#15560: GROUP_CONCAT wasn't ready for WITH ROLLUP queries
        Added the flag 'force_copy_fields' to the Item_func_group_concat and Item_sum_count_distinct classes.
      8d5277a7
  17. 28 Mar, 2006 2 commits
    • unknown's avatar
      Removed forgotten comment line in sql_select.cc. · 260a84fc
      unknown authored
      sql/sql_select.cc:
        Forgot to remove commented line in previous commit.
      260a84fc
    • unknown's avatar
      Post review fixes for BUG#16474: SP crashed MySQL. · 8af67658
      unknown authored
      mysql-test/r/ps.result:
        Added test coverage for "order by" in prepared statements (related to BUG#16474).
      mysql-test/r/sp.result:
        Added reference to test case for BUG#16474.
      mysql-test/t/ps.test:
        Added test coverage for "order by" in prepared statements (related to BUG#16474).
      mysql-test/t/sp.test:
        Added reference to test case for BUG#16474.
      sql/sql_select.cc:
        Fixed comment and test for basic_const_item() instead of is_splocal().
      8af67658
  18. 14 Mar, 2006 1 commit
    • unknown's avatar
      sql_select.cc: · cf0bd7e1
      unknown authored
        Afterfix for bug#17366: Unchecked Item_int results in server crash
      
      
      sql/sql_select.cc:
        Afterfix for bug#17366: Unchecked Item_int results in server crash
      cf0bd7e1
  19. 13 Mar, 2006 1 commit
    • unknown's avatar
      Fixed bug#17366: Unchecked Item_int results in server crash · 1da91c4a
      unknown authored
      When there is conjunction of conds, the substitute_for_best_equal_field()
      will call the eliminate_item_equal() function in loop to build final
      expression. But if eliminate_item_equal() finds that some cond will always
      evaluate to 0, then that cond will be substituted by Item_int with value ==
      0. In this case on the next iteration eliminate_item_equal() will get that 
      Item_int and treat it as Item_cond. This is leads to memory corruption and
      server crash on cleanup phase.
      
      To the eliminate_item_equal() function was added DBUG_ASSERT for checking
      that all items treaten as Item_cond are really Item_cond.
      The substitute_for_best_equal_field() now checks that if
      eliminate_item_equal() returns Item_int and it's value is 0 then this 
      value is returned as the result of whole conjunction.
      
      
      mysql-test/t/subselect.test:
        Added test for bug#17366: Unchecked Item_int results in server crash
      mysql-test/r/subselect.result:
         Added test for bug#17366: Unchecked Item_int results in server crash
      sql/sql_select.cc:
        Fixed bug#17366: Unchecked Item_int results in server crash
         
        To the eliminate_item_equal() function was added DBUG_ASSERT for checking
        that all items treaten as Item_cond are really Item_cond.
        The substitute_for_best_equal_field() now checks that if
        eliminate_item_equal() returns something other than Item_cond and if it is
        then this value is returned as the result of whole conjunction.
      1da91c4a
  20. 10 Mar, 2006 1 commit
    • unknown's avatar
      Fixed BUG#16474: SP crashed MySQL · 311d04dd
      unknown authored
        fix_fields() was not called for "order by" variables if the type was a
        "constant integer", and thus interpreted as a column index.
        However, a local variable is an expression and should not be interpreted
        as a column index. Instead it behaves just like when using a user variable
        for instance (i.e. it will not affect the ordering).
      
      
      
      mysql-test/r/sp.result:
        Updated results for new test case (BUG#16474).
      mysql-test/t/sp.test:
        New test case for BUG#16474.
      sql/sql_select.cc:
        When processing order list,
      311d04dd
  21. 14 Feb, 2006 2 commits
    • unknown's avatar
      dbug changes: · d8078c16
      unknown authored
      1. dbug state is now local to a thread
      2. new macros: DBUG_EXPLAIN, DBUG_EXPLAIN_INITIAL,
         DBUG_SET, DBUG_SET_INITIAL, DBUG_EVALUATE, DBUG_EVALUATE_IF
      3. macros are do{}while(0) wrapped
      4. incremental modifications to the dbug state (e.g. "+d,info:-t")
      5. dbug code cleanup, style fixes
      6. _db_on_ and DEBUGGER_ON/OFF removed
      7. rest of MySQL code fixed because of 3 (missing ;) and 6
      8. dbug manual updated
      9. server variable @@debug (global and local) to control dbug from SQL!
      a. -#T to print timestamps in the log
      
      
      BitKeeper/deleted/.del-readme.prof~2f3bae1550a0038d:
        Delete: dbug/readme.prof
      client/mysqlslap.c:
        typo fixed
      configure.in:
        test for sleep() too
      dbug/dbug.c:
        thread local dbug settings
        DBUG_EXPLAIN,DBUG_EXPLAIN_INITIAL,DBUG_SET,DBUG_SET_INITIAL
        style changes to be more in line with MySQL code
        cleanup (many mallocs removed)
        incremental modification of dbug state (e.g. DBUG_PUSH("+t:-d,info"))
        DBUG_SET, _db_explain_
        -#T
      dbug/monty.doc:
        obsolete and duplicate docs removed
      dbug/user.r:
        new features documented
      include/my_dbug.h:
        correct do{}while wrapping
        thread local dbug settings
        DBUG_EXPLAIN,DBUG_EXPLAIN_INITIAL,DBUG_SET,DBUG_SET_INITIAL
        DBUG_EVALUATE,DBUG_EVALUATE_IF
      libmysql/libmysql.c:
        remove _db_on_ and DEBUGGER_ON/OFF
      mysys/my_init.c:
        missed DBUG_RETURN
      mysys/my_thr_init.c:
        bugfix - transaction id's are unsigned
      mysys/testhash.c:
        remove _db_on_ and DEBUGGER_ON/OFF
      sql/ha_myisammrg.cc:
        missed ;
      sql/ha_ndbcluster.cc:
        remove _db_on_ and DEBUGGER_ON/OFF
        missed ;
      sql/ha_ndbcluster_binlog.cc:
        remove _db_on_ and DEBUGGER_ON/OFF
        missed ;
      sql/item_cmpfunc.cc:
        missed ;
      sql/lock.cc:
        missed DBUG_RETURN
      sql/log_event.cc:
        missed ;
      sql/mysqld.cc:
        remove _db_on_ and DEBUGGER_ON/OFF
        missed ;
        DBUG_SET_INITIAL
      sql/opt_range.cc:
        remove _db_on_ and DEBUGGER_ON/OFF
      sql/set_var.cc:
        class sys_var_thd_dbug and "debug" server variable
      sql/set_var.h:
        class sys_var_thd_dbug and "debug" server variable
      sql/slave.cc:
        missed ;
      sql/sql_cache.cc:
        missed ;
      sql/sql_plugin.cc:
        missed ;
      sql/sql_select.cc:
        remove _db_on_ and DEBUGGER_ON/OFF
      storage/heap/hp_test2.c:
        remove _db_on_ and DEBUGGER_ON/OFF
      storage/myisam/ft_eval.c:
        remove _db_on_ and DEBUGGER_ON/OFF
      storage/myisam/ft_test1.c:
        remove _db_on_ and DEBUGGER_ON/OFF
      storage/myisam/mi_open.c:
        remove _db_on_ and DEBUGGER_ON/OFF
        missed ;
      storage/myisam/mi_test1.c:
        remove _db_on_ and DEBUGGER_ON/OFF
      storage/myisam/mi_test2.c:
        remove _db_on_ and DEBUGGER_ON/OFF
      storage/myisam/mi_test3.c:
        remove _db_on_ and DEBUGGER_ON/OFF
      storage/ndb/src/ndbapi/DictCache.cpp:
        missed ;
      storage/ndb/src/ndbapi/NdbTransaction.cpp:
        missed ;
      tests/mysql_client_test.c:
        remove _db_on_ and DEBUGGER_ON/OFF
      d8078c16
    • unknown's avatar
      Fixed bug #16603. · d5bbbb87
      unknown authored
      A subquery transformation changes the HAVING clause of the embedding query if the subquery contains
      a GROUP BY clause. Yet the split_sum_func2 function was not applied to the modified HAVING clause.
      This could result in wrong answers.
      
      
      mysql-test/r/subselect.result:
        Added a test case for bug #16603.
      mysql-test/t/subselect.test:
        Added a test case for bug #16603.
      d5bbbb87
  22. 08 Feb, 2006 1 commit
    • unknown's avatar
      Fixed bug#16752 Binary table files created in mysqld v4.1 caused buffer overrun · c980ff0c
      unknown authored
        and possibly server crash in mysqld v5.0.
      
      Reported MyISAM table was created in mysqld 4.1 and contains varchar field.
      When binary files of that table was moved to 5.0, mysqld treats that varchar 
      field as a string field. 
      In order to make grouping server calculates group buffer, and because
      that field is string server assumes it has fixed length and doesn't add
      space for length, but later that field is converted to varchar field. 
      Due to this, when field values were actually copied, additional space for
      length bytes is taken and buffer overrun occurs, which may lead to server crash.
      
      The calc_group_buffer() function now reserves additional space for length
      bytes for VAR_STRING fields, like for VARCHAR fields.
      
      
      sql/sql_select.cc:
        Fixed bug#16752 Binary table files created in mysqld v4.1 caused buffer overrun and possibly server crash in mysqld v5.0.
        The calc_group_buffer() function now reserves additional space for length
        bytes for VAR_STRING fields, like for VARCHAR fields.
      c980ff0c
  23. 03 Feb, 2006 2 commits
  24. 02 Feb, 2006 1 commit
    • unknown's avatar
      Fixed bug #16382. · 06b5e499
      unknown authored
      When an ambiguous field name is used in a group by clause a warning is issued
      in the find_order_in_list function by a call to push_warning_printf.
      An expression that was not always valid was passed to this call as the field
      name parameter.
      
      
      mysql-test/r/view.result:
        Added a test case for bug #16382.
      mysql-test/t/view.test:
        Added a test case for bug #16382.
      06b5e499
  25. 01 Feb, 2006 1 commit
    • unknown's avatar
      FIxed bug #14927. · a38cb38b
      unknown authored
      A query with a group by and having clauses could return a wrong
      result set if the having condition contained a constant conjunct 
      evaluated to FALSE.
      It happened because the pushdown condition for table with
      grouping columns lost its constant conjuncts.
      Pushdown conditions are always built by the function make_cond_for_table
      that ignores constant conjuncts. This is apparently not correct when
      constant false conjuncts are present.
      
      
      mysql-test/r/having.result:
        Added A test case for bug #14927.
      mysql-test/t/having.test:
        Added A test case for bug #14927.
      sql/sql_lex.cc:
        Fixed bug #14927.
        Initialized fields for having conditions in  st_select_lex::init_query().
      sql/sql_lex.h:
        Fixed bug #14927.
        Added a field to restore having condititions for execution in SP and PS.
      sql/sql_prepare.cc:
        Fixed bug #14927.
        Added code to restore havinf conditions for execution in SP and PS.
      sql/sql_select.cc:
        Fixed bug #14927.
        Performed evaluation of constant expressions in having clauses.
        If the having condition contains a constant conjunct that is always false
        an empty result set is returned after the optimization phase.
        In this case the corresponding EXPLAIN command now returns 
        "Impossible HAVING" in the last column.
      a38cb38b
  26. 28 Jan, 2006 1 commit
    • unknown's avatar
      Fixed bug #16260. · ab55c1ea
      unknown authored
      The problem has manifested itself in the cases when we have a nested outer join
      for which it can be inferred that one of the inner tables is a single row table.
      
      
      mysql-test/r/join_nested.result:
        Added a test case for bug #16260.
      mysql-test/t/join_nested.test:
        Added a test case for bug #16260.
      sql/sql_select.cc:
        Fixed bug #16260.
        The problem has manifested itself in the cases when we have a nested outer join
        for which it can be inferred that one of the inner tables is a single row table.
        A table is never considered as a const table if it is used in a nested join 
        that serves as an inner operand of an outer join.
      ab55c1ea
  27. 24 Jan, 2006 1 commit
  28. 20 Jan, 2006 1 commit
    • unknown's avatar
      Fix for BUG#15588: String overrun during sp-vars.test · 08da1b93
      unknown authored
      The bug appears after implementation of WL#2984
      (Make stored routine variables work according to the standard).
      
      
      mysql-test/r/type_varchar.result:
        Update result file.
      mysql-test/t/type_varchar.test:
        Add a test for BUG#15588.
      sql/field.cc:
        - use memmove() instead of memcpy() -- after implementation of WL#2984
          (Make stored routine variables work according to the standard) it is
          possible to store in the field the value from this field. For instance,
          this can happen for the following statement:
            SET sp_var = SUBSTR(sp_var, 1, 3);
      sql/sp_head.cc:
        - Work correctly with String:
          - String length has to be be reset before use;
          - qs_append() does not allocate memory, so the memory should
            be reserved beforehand.
      sql/sql_select.cc:
        Polishing: should have been done in WL#2984.
      08da1b93
  29. 18 Jan, 2006 1 commit
    • unknown's avatar
      Excluded posibility of tmp_table_param.copy_field double deletion (BUG#14851). · b9e6d330
      unknown authored
      mysql-test/r/kill.result:
        BUG#14851 test
      mysql-test/t/kill.test:
        BUG#14851 test
      sql/sql_class.cc:
        Debug prints are added.
      sql/sql_select.cc:
        Allocation of tmp_join fixed to involve constructor (it is not related to the bug directly but might cause other problems).
        Excluded posibility of tmp_table_param.copy_field double deletion (BUG#14851).
      sql/sql_select.h:
        JOINs constructor added, initialization of them fixed (it is not related to the bug directly but might cause other problems).
      b9e6d330
  30. 17 Jan, 2006 1 commit
  31. 13 Jan, 2006 2 commits
  32. 12 Jan, 2006 1 commit