An error occurred fetching the project authors.
- 24 May, 2006 1 commit
-
-
unknown authored
After merge fix sql/sql_select.cc: After merge fix
-
- 23 May, 2006 1 commit
-
-
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
-
- 22 May, 2006 1 commit
-
-
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.
-
- 21 May, 2006 1 commit
-
-
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.
-
- 10 May, 2006 1 commit
-
-
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
-
- 09 May, 2006 1 commit
-
-
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
-
- 07 May, 2006 3 commits
-
-
unknown authored
-
unknown authored
find_best() call best_access_path().
-
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.
-
- 06 May, 2006 1 commit
-
-
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.
-
- 03 May, 2006 1 commit
-
-
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.
-
- 21 Apr, 2006 1 commit
-
-
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.
-
- 20 Apr, 2006 2 commits
-
-
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.
-
unknown authored
-
- 12 Apr, 2006 1 commit
-
-
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.
-
- 04 Apr, 2006 1 commit
-
-
unknown authored
-
- 01 Apr, 2006 1 commit
-
-
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.
-
- 30 Mar, 2006 2 commits
-
-
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
-
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.
-
- 29 Mar, 2006 1 commit
-
-
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.
-
- 28 Mar, 2006 2 commits
-
-
unknown authored
sql/sql_select.cc: Forgot to remove commented line in previous commit.
-
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().
-
- 14 Mar, 2006 1 commit
-
-
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
-
- 13 Mar, 2006 1 commit
-
-
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.
-
- 10 Mar, 2006 1 commit
-
-
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,
-
- 14 Feb, 2006 2 commits
-
-
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
-
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.
-
- 08 Feb, 2006 1 commit
-
-
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.
-
- 03 Feb, 2006 2 commits
- 02 Feb, 2006 1 commit
-
-
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.
-
- 01 Feb, 2006 1 commit
-
-
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.
-
- 28 Jan, 2006 1 commit
-
-
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.
-
- 24 Jan, 2006 1 commit
-
-
unknown authored
Fill schema tables with data before filesort if it's necessary mysql-test/r/information_schema.result: Fix for bug#15307 GROUP_CONCAT() with ORDER BY returns empty set on information_schema(2nd ver) test result mysql-test/t/information_schema.test: Fix for bug#15307 GROUP_CONCAT() with ORDER BY returns empty set on information_schema(2nd ver) test case
-
- 20 Jan, 2006 1 commit
-
-
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.
-
- 18 Jan, 2006 1 commit
-
-
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).
-
- 17 Jan, 2006 1 commit
-
-
unknown authored
sql/sql_select.cc: Backport from 5.0, catch the new errno that is returned
-
- 13 Jan, 2006 2 commits
- 12 Jan, 2006 1 commit
-
-
unknown authored
-