- 17 Sep, 2006 1 commit
-
-
unknown authored
by master and slave is made. mysql-test/r/rpl_view.result: BUG#19419: VIEW: View that the column name is different by master and slave is made. Fixed result for the added test case. mysql-test/t/rpl_view.test: BUG#19419: VIEW: View that the column name is different by master and slave is made. Added test case. sql/sql_parse.cc: BUG#19419: VIEW: View that the column name is different by master and slave is made. Fixed: Add column_list to to the view creation statement which is written to binlog.
-
- 15 Sep, 2006 1 commit
-
-
unknown authored
-
- 14 Sep, 2006 1 commit
-
-
unknown authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge ndb/src/kernel/blocks/dbdih/DbdihMain.cpp: Auto merged sql/ha_ndbcluster.cc: Auto merged sql/sql_class.h: Auto merged sql/sql_yacc.yy: Auto merged client/mysqldump.c: Merge main->rpl mysql-test/r/mysqldump.result: Merge main->rpl mysql-test/t/mysqldump.test: Merge main->rpl
-
- 12 Sep, 2006 1 commit
-
-
unknown authored
The cause of the bug was an incomplete fix for bug 18080. The problem was that setup_tables() unconditionally reset the name resolution context to its 'tables' argument, which pointed to the first table of an SQL statement. The bug fix limits resetting of the name resolution context in setup_tables() only in the cases when the context was not set by earlier parser/optimizer phases. mysql-test/r/insert_select.result: Test for BUG#21774. mysql-test/t/insert_select.test: Test for BUG#21774. sql/sql_base.cc: Do not reset the name resolution contect unconditionally. Instead set the context to 'tables' only if it was not set before calling setup_tables(). sql/sql_insert.cc: Added asserts to make sure that in the case of INSERT ... VALUES ... statements it is not necessary to reset the name resolution context to the first table, because there is only one table in the list of tables anyway. The actual code is not removed in order not to confuse it with the actual bug fix. sql/sql_parse.cc: Removed unnecessary reset of the name resolution context. The context is anyway unconditionally reset in mysql_insert() and mysql_prepare_insert().
-
- 11 Sep, 2006 4 commits
-
-
unknown authored
-
unknown authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge sql/sql_yacc.yy: Manual merge (rpl 4.1 -> rpl 5.0)
-
unknown authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge client/mysqldump.c: Auto merged mysql-test/r/mysqldump.result: Manual merge (main -> rpl 5.0) mysql-test/t/mysqldump.test: Manual merge (main -> rpl 5.0)
-
unknown authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge
-
- 04 Sep, 2006 2 commits
-
-
unknown authored
into perch.ndb.mysql.com:/home/jonas/src/50-work sql/log.cc: Auto merged sql/sql_class.h: Auto merged sql/sql_repl.cc: merge
-
unknown authored
fix deadlock if master switches log file in parallell with "show master logs" sql/log.cc: add raw_get_current_log which dont take log mutex sql/sql_class.h: add raw_get_current_log which dont take log mutex sql/sql_repl.cc: Fix lock order i.e first log_lock then index_lock
-
- 30 Aug, 2006 1 commit
-
-
unknown authored
there is a bunch of dups. It has been decided to declare this feature as deprecated. sql/sql_yacc.yy: deprecation macro
-
- 28 Aug, 2006 2 commits
- 26 Aug, 2006 3 commits
- 25 Aug, 2006 3 commits
-
-
unknown authored
into mysql.com:/home/psergey/mysql-5.0-bug16255-merge
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
unknown authored
const tables. This resulted in choosing extremely inefficient execution plans in same cases when distribution of data in joined were skewed (see the customer test case for the bug). mysql-test/r/select.result: Added a test case for bug #21390: wrong estimate of rows after elimination of const tables. Includded a test case that checks the code added by the patch that handles outer joins with no matches after substitution of a const table in an efficient way. mysql-test/t/select.test: Added a test case for bug #21390: wrong estimate of rows after elimination of const tables. Included a test case that checks the code added by the patch that handles outer joins with no matches after substitution of a const table in an efficient way. sql/sql_select.cc: Fixed bug #21390: wrong estimate of rows after elimination of const tables. This resulted in choosing extremely inefficient execution plans in same cases when distribution of data in joined were skewed (see the customer test case for the bug). Also added the code to handle outer joins with no matches after substitution of a const table in an efficient way. Corrected calculation of the null rejecting key conditions.
-
- 24 Aug, 2006 7 commits
-
-
unknown authored
Corrected fix for bug#18165 sql/opt_range.cc: Corrected fix for bug#18165
-
unknown authored
Corrected fix for bug#18165 sql/opt_range.cc: Corrected fix for bug#18165
-
unknown authored
-
unknown authored
mysql-test/r/subselect.result: BUG#16255: A proper testcase mysql-test/t/subselect.test: BUG#16255: A proper testcase
-
unknown authored
Must not use Item_direct_ref in HAVING because it points to the new value (witch is not yet calculated for the first row). mysql-test/r/subselect.result: Bug #16255: Subquery in where - test case mysql-test/t/subselect.test: Bug #16255: Subquery in where - test case sql/item_subselect.cc: Bug #16255: Subquery in where Must not use Item_direct_ref in HAVING because it points to the new value (witch is not yet calculated for the first row).
-
unknown authored
into perch.ndb.mysql.com:/home/jonas/src/50-work ndb/src/ndbapi/NdbScanOperation.cpp: Auto merged
-
unknown authored
read TransactionDeadlockTimeout (for scans) to cater for insane settings ndb/src/ndbapi/NdbScanOperation.cpp: read TransactionDeadlockTimeout to cater for insane settings
-
- 23 Aug, 2006 3 commits
-
-
unknown authored
Corrected test case for the bug#21261 sql_parse.cc: Corrected fix for bug#21261 mysql-test/t/view.test: Corrected test case for the bug#21261 mysql-test/r/view.result: Corrected test case for the bug#21261 sql/sql_parse.cc: Corrected fix for bug#21261
-
unknown authored
into lamia.home:/home/timka/mysql/src/5.0-bug-21456 mysql-test/r/distinct.result: Merge the fix for BUG#21456 mysql-test/t/distinct.test: Merge the fix for BUG#21456 sql/sql_select.cc: Merge the fix for BUG#21456
-
unknown authored
GROUP BY/DISTINCT pruning optimization must be done before ORDER BY optimization because ORDER BY may be removed when GROUP BY/DISTINCT sorts as a side effect, e.g. in SELECT DISTINCT <non-key-col>,<pk> FROM t1 ORDER BY <non-key-col> DISTINCT must be removed before ORDER BY as if done the other way around it will remove both. mysql-test/r/distinct.result: Test for BUG#21456. mysql-test/t/distinct.test: Test for BUG#21456. sql/sql_select.cc: Bug #21456: SELECT DISTINCT(x) produces incorrect results when using order by GROUP BY/DISTINCT pruning optimization must be done before ORDER BY optimization because ORDER BY may be removed when GROUP BY/DISTINCT sorts as a side effect.
-
- 22 Aug, 2006 11 commits
-
-
unknown authored
into moonbone.local:/work/21475-fix-5.0-opt-mysql
-
unknown authored
Additional fix for bug #21475 item_func.h, item_func.cc: Additional fix for bug#16861 sql/item_func.h: Additional fix for bug#16861 sql/item_func.cc: Additional fix for bug#16861 sql/item_cmpfunc.cc: Additional fix for bug #21475 sql/item.cc: Additional fix for bug #21475
-
unknown authored
into salvation.intern.azundris.com:/home/tnurnberg/work/mysql-5.0-maint-20987
-
unknown authored
into salvation.intern.azundris.com:/home/tnurnberg/work/mysql-5.0-maint-20987
-
unknown authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/merge/mysql-5.0
-
unknown authored
into rurik.mysql.com:/home/igor/mysql-5.0-opt
-
unknown authored
into sunlight.local:/local_work/16861-bug-5.0-mysql sql/sql_select.cc: Auto merged
-
unknown authored
used. Sorting by RAND() uses a temporary table in order to get a correct results. User defined variable was set during filling the temporary table and later on it is substituted for its value from the temporary table. Due to this it contains the last value stored in the temporary table. Now if the result_field is set for the Item_func_set_user_var object it updates variable from the result_field value when being sent to a client. The Item_func_set_user_var::check() now accepts a use_result_field parameter. Depending on its value the result_field or the args[0] is used to get current value. mysql-test/r/user_var.result: Added a test case for bug#16861: User defined variable can have a wrong value if a tmp table was used. mysql-test/t/user_var.test: Added a test case for bug#16861: User defined variable can have a wrong value if a tmp table was used. sql/item_func.cc: Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Now if the result_field is set for the Item_func_set_user_var object it updates variable from the result_field value when being sent to a client. The Item_func_set_user_var::check() now accepts a use_result_field parameter. Depending on its value the result_field or the args[0] is used to get current value. sql/item_func.h: Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Added a new SUSERVAR_FUNC function type. Updated the Item_func_set_user_var::check() function declaration. Added the Item_func_set_user_var::send() member function. sql/set_var.cc: Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Modified to use updated Item_func_set_user_var::check() function. sql/sql_class.cc: Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Modified to use updated Item_func_set_user_var::check() function. sql/sql_select.cc: Fixed bug#16861: User defined variable can have a wrong value if a tmp table was used. Now an Item_func_set_user_var object isn't substituted for an Item_field object after filling a temporary table.
-
unknown authored
into moonbone.local:/work/21475-bug-5.0-opt-mysql
-
unknown authored
into salvation.intern.azundris.com:/home/tnurnberg/work/mysql-5.0-maint-20411 sql/sql_acl.cc: Auto merged
-
unknown authored
when X.509 subject was required for a connect, we tested whether it was the right one, but did not refuse the connexion if not. fixed. (corrected CS now --replace_results socket-path) mysql-test/r/openssl_1.result: Bug#20411: "GRANT ... REQUIRE ISSUER nnn AND SUBJECT mmm" fails to require both test not only whether we can connect with a correct X.509 subject when one is required, but also assure that we can't without one. mysql-test/t/openssl_1.test: Bug#20411: "GRANT ... REQUIRE ISSUER nnn AND SUBJECT mmm" fails to require both test not only whether we can connect with a correct X.509 subject when one is required, but also assure that we can't without one. sql/sql_acl.cc: Bug#20411: "GRANT ... REQUIRE ISSUER nnn AND SUBJECT mmm" fails to require both actually refuse connexion if X.509 is required, but does not match. kudos to Al Smith.
-