- 27 Oct, 2006 1 commit
-
-
unknown authored
a updatable view. When there's a VIEW on a base table that have AUTO_INCREMENT column, and this VIEW doesn't provide an access such column, after INSERT to such VIEW LAST_INSERT_ID() did not return the value just generated. This behaviour is intended and correct, because if the VIEW doesn't list some columns then these columns are effectively hidden from the user, and so any side effects of inserting default values to them. However, there was a bug that such statement inserting into a view would reset LAST_INSERT_ID() instead of leaving it unchanged. This patch restores the original value of LAST_INSERT_ID() instead of resetting it to zero. mysql-test/r/view.result: Add result for bug#22584: last_insert_id not updated after inserting a record through a updatable view. mysql-test/t/view.test: Add test case for bug#22584: last_insert_id not updated after inserting a record through a updatable view. sql/sql_parse.cc: When we have inserted into a view, and AUTO_INCREMENT column is not accessed from this view, instead of setting LAST_INSERT_ID to zero set it to the value it had before this statement was executed.
-
- 20 Oct, 2006 3 commits
-
-
unknown authored
server-tools/instance-manager/guardian.cc: 1. Removed unused stop_instances_arg from request_shutdown() and stop_instances() methods. 2. Changed log-output statements so that instance name is passed correctly (char *, not LEX_STRING) server-tools/instance-manager/guardian.h: Removed unused stop_instances_arg from request_shutdown() and stop_instances() methods. server-tools/instance-manager/instance.cc: Removed unused stop_instances_arg from request_shutdown() and stop_instances() methods. server-tools/instance-manager/listener.cc: Be more verbose in log. server-tools/instance-manager/manager.cc: Removed unused stop_instances argument.
-
unknown authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg15228-2 sql/sql_trigger.cc: Auto merged sql/sql_view.cc: Auto merged
-
unknown authored
warnings in sql_trigger.cc and sql_view.cc". According to the current version of C++ standard offsetof() macro can't be used for non-POD types. So warnings were emitted when we tried to use this macro for TABLE_LIST and Table_triggers_list classes. Note that despite of these warnings it was probably safe thing to do. This fix tries to circumvent this limitation by implementing custom version of offsetof() macro to be used with these classes. This hack should go away once we will refactor File_parser class. Alternative approaches such as disabling this warning for sql_trigger.cc/sql_view.cc or for the whole server were considered less explicit. Also I was unable to find a way to disable particular warning for particular _part_ of file in GCC. sql/parse_file.h: Introduced auxillary macro which can be used instead of offsetof() to get offsets of members in class for non-POD types without getting warnings (assuming that all instances of the class has same offsets for same members). sql/sql_trigger.cc: Use my_offsetof() macro instead of standard offsetof() macro with Table_triggers_list class in order to avoid warnings (offsetof() cannot be used for non-POD types according to the standard). sql/sql_view.cc: Use my_offsetof() macro instead of standard offsetof() macro with TABLE_LIST class in order to avoid warnings (offsetof() cannot be used for non-POD types according to the standard).
-
- 19 Oct, 2006 3 commits
-
-
unknown authored
This patch reverts a change introduced by Bug 6951, which incorrectly set thd->abort_on_warning for stored procedures. As per internal discussions about the SQL_MODE=TRADITIONAL, the correct behavior is to *not* abort on warnings even inside an INSERT/UPDATE trigger. Tests for Stored Procedures, Stored Functions, Triggers involving SQL_MODE have been included or revised, to reflect the intended behavior. (reposting approved patch, to work around source control issues, no review needed) mysql-test/include/sp-vars.inc: Tests for SQL_MODE='TRADITIONAL' mysql-test/r/sp-vars.result: Tests for SQL_MODE='TRADITIONAL' mysql-test/r/sp.result: Tests for SQL_MODE='TRADITIONAL' mysql-test/r/trigger.result: Tests for SQL_MODE='TRADITIONAL' mysql-test/t/sp-vars.test: Tests for SQL_MODE='TRADITIONAL' mysql-test/t/sp.test: Tests for SQL_MODE='TRADITIONAL' mysql-test/t/trigger.test: Tests for SQL_MODE='TRADITIONAL' sql/sp_head.cc: For SQL_MODE='TRADITIONAL', thd->abort_on_warning should be set only when assigning a *column*
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21856 sql/sql_parse.cc: Auto merged mysql-test/r/ps.result: Manual merge. mysql-test/t/ps.test: Manual merge.
-
unknown authored
When statement to be prepared contained CREATE PROCEDURE, CREATE FUNCTION or CREATE TRIGGER statements with a syntax error in it, the preparation would fail with syntax error message, but the memory could be corrupted. The problem occurred because we switch memroot when parse stored routine or trigger definitions, and on parse error we restored the original memroot only after performing some memory operations. In more detail: - prepared statement would activate its own memory root to parse the definition of the stored procedure. - SP would reset this memory root with its own memory root to parse SP statements - a syntax error would happen - prepared statement would restore the original memory root - stored procedure would restore what it thinks was the original memory root, but actually was the statement memory root. That led to double free - in destruction of the statement and in a next call to mysql_parse(). The solution is to restore memroot right after the failed parsing. mysql-test/r/ps.result: Add result for bug#21856: Prepared Statements: crash if bad create. mysql-test/t/ps.test: Add test case for bug#21856: Prepared Statements: crash if bad create. sql/sql_parse.cc: On parse error if thd->lex->sphead is set we have to free sp_head object to restore statement memroot, if it was switched during parsing. The change here is for safety, currently query_cache_abort() and lex->unit.cleanup() calls do not use current memroot. sql/sql_prepare.cc: On parse error if thd->lex->sphead is set we have to free sp_head object to restore statement memroot, if it was switched during parsing.
-
- 18 Oct, 2006 1 commit
-
-
unknown authored
(COUNT(*) = 1) not working in SELECT inside prepared statement. Note: the warning was introduced in 5.0 and 5.1, 4.1 is OK with the original fix. The problem was that in 5.0 and 5.1 clear() for group functions may access hybrid_type member, and this member is initialized in fix_fields(). So we should not call clear() from item cleanup() methods, as cleanup() may be called for unfixed items. sql/item_sum.cc: Do not call clear() from item cleanup() methods, as cleanup() may be called for unfixed items, and clear() assumes the item was fixed. sql/item_sum.h: Do not call clear() from item cleanup() methods, as cleanup() may be called for unfixed items, and clear() assumes the item was fixed.
-
- 17 Oct, 2006 2 commits
-
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21726 mysql-test/r/rpl_insert_id.result: Auto merged mysql-test/t/rpl_insert_id.test: Auto merged sql/item_func.cc: Auto merged sql/item_func.h: Auto merged sql/log_event.cc: Auto merged sql/set_var.cc: Auto merged sql/sql_class.h: Auto merged sql/sql_insert.cc: Auto merged sql/sql_load.cc: Auto merged sql/sql_parse.cc: Auto merged sql/sql_select.cc: Auto merged sql/sql_update.cc: Auto merged tests/mysql_client_test.c: Auto merged
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21726 mysql-test/r/rpl_insert_id.result: Use local. mysql-test/t/rpl_insert_id.test: Use local. sql/item_func.cc: Use local. sql/item_func.h: Use local. sql/log_event.cc: Use local. sql/set_var.cc: Use local. sql/sql_class.h: Use local. sql/sql_insert.cc: Use local. sql/sql_load.cc: Use local. sql/sql_parse.cc: Use local. sql/sql_select.cc: Use local. sql/sql_update.cc: Use local. tests/mysql_client_test.c: Use local.
-
- 12 Oct, 2006 3 commits
-
-
unknown authored
mysql-test/t/sp-error.test: Move test for bug#20953 to the end of file.
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug20953 mysql-test/r/view.result: Auto merged mysql-test/t/sp-error.test: Auto merged mysql-test/t/view.test: Auto merged sql/sql_lex.cc: Auto merged sql/sql_lex.h: Auto merged sql/sql_view.cc: Auto merged sql/sql_yacc.yy: Auto merged mysql-test/r/sp-error.result: Manual merge.
-
unknown authored
should fail to create The problem was that this type of errors was checked during view creation, which doesn't happen when CREATE VIEW is a statement of a created stored routine. The solution is to perform the checks at parse time. The idea of the fix is that the parser checks if a construction just parsed is allowed in current circumstances by testing certain flags, and this flags are reset for VIEWs. The side effect of this change is that if the user already have such bogus routines, it will now get a error when trying to do SHOW CREATE PROCEDURE proc; (and some other) and when trying to execute such routine he will get ERROR 1457 (HY000): Failed to load routine test.p5. The table mysql.proc is missing, corrupt, or contains bad data (internal code -6) However there should be very few such users (if any), and they may (and should) drop these bogus routines. mysql-test/r/sp-error.result: Add result for bug#20953: create proc with a create view that uses local vars/params should fail to create. mysql-test/r/view.result: Update results. mysql-test/t/sp-error.test: Add test case for bug#20953: create proc with a create view that uses local vars/params should fail to create. mysql-test/t/view.test: Add second test for variable in a view. Remove SP variable in a view test, as it tests wrong behaviour. Add test for derived table in a view. sql/sql_lex.cc: Remove LEX::variables_used. sql/sql_lex.h: Remove LEX::variables_used and add st_parsing_options structure and LEX::parsing_options member. sql/sql_view.cc: Move some error checking to sql/sql_yacc.yy. sql/sql_yacc.yy: Check for disallowed syntax in a CREATE VIEW at parse time to rise a error when it is used inside CREATE PROCEDURE and CREATE FUNCTION, as well as by itself.
-
- 10 Oct, 2006 10 commits
-
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21354
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug19111
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21354 mysql-test/t/func_gconcat.test: Auto merged sql/item_sum.cc: Auto merged mysql-test/r/ps.result: Manual merge. mysql-test/t/ps.test: Manual merge.
-
unknown authored
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21354 mysql-test/t/func_gconcat.test: Auto merged sql/item_sum.cc: Auto merged mysql-test/r/ps.result: Manual merge. mysql-test/t/ps.test: Manual merge. sql/item_sum.h: Manual merge.
-
unknown authored
statement. The problem was that during statement re-execution if the result was empty the old result could be returned for group functions. The solution is to implement proper cleanup() method in group functions. mysql-test/r/ps.result: Add result for bug#21354: (COUNT(*) = 1) not working in SELECT inside prepared statement. mysql-test/t/func_gconcat.test: Add a comment that the test case is from bug#836. mysql-test/t/ps.test: Add test case for bug#21354: (COUNT(*) = 1) not working in SELECT inside prepared statement. sql/item_sum.cc: Call clear() in Item_sum_count::cleanup(). sql/item_sum.h: Add comments. Add proper cleanup() methods. Change Item_sum::no_rows_in_result() to call clear() instead of reset(), as the latter also issues add(), and there is nothing to add when there are no rows in result.
-
unknown authored
into mysql.com:/home/cps/mysql/trees/mysql-5.0-virgin
-
unknown authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug19111 sql/sql_base.cc: Auto merged mysql-test/r/view.result: Manual merge. mysql-test/t/view.test: Manual merge.
-
unknown authored
In a trigger or a function used in a statement it is possible to do SELECT from a table being modified by the statement. However, encapsulation of such SELECT into a view and selecting from a view instead of direct SELECT was not possible. This happened because tables used by views (which in their turn were used from functions/triggers) were not excluded from checks in unique_table() routine as it happens for the rest of tables added to the statement table list for prelocking. With this fix we ignore all such tables in unique_table(), thus providing consistency: inside a trigger or a functions SELECT from a view may be used where plain SELECT is allowed. Modification of the same table from function or trigger is still disallowed. Also, this patch doesn't affect the case where SELECT from the table being modified is done outside of function of trigger, such SELECTs are still disallowed (this limitation and visibility problem when function select from a table being modified are subjects of bug 21326). See also bug 22427. mysql-test/r/view.result: Add result for bug#19111: TRIGGERs selecting from a VIEW on the firing base table fail. mysql-test/t/view.test: Add test case for bug#19111: TRIGGERs selecting from a VIEW on the firing base table fail. sql/sql_base.cc: In unique_table() do not check tables that are used in a stored function or a trigger ('prelocking_placeholder' is set). If such function or a trigger will attempt to modify a table, the error will be given, however select is allowed there.
-
unknown authored
into bodhi.local:/opt/local/work/mysql-5.0-runtime mysql-test/mysql-test-run.pl: Auto merged
-
- 09 Oct, 2006 1 commit
-
-
unknown authored
The syntax of the CALL statement, to invoke a stored procedure, has been changed to make the use of parenthesis optional in the argument list. With this change, "CALL p;" is equivalent to "CALL p();". While the SQL spec does not explicitely mandate this syntax, supporting it is needed for practical reasons, for integration with JDBC / ODBC connectors. Also, warnings in the sql/sql_yacc.yy file, which were not reported by Bison 2.1 but are now reported by Bison 2.2, have been fixed. The warning found were: bison -y -p MYSQL -d --debug --verbose sql_yacc.yy sql_yacc.yy:653.9-18: warning: symbol UNLOCK_SYM redeclared sql_yacc.yy:656.9-17: warning: symbol UNTIL_SYM redeclared sql_yacc.yy:658.9-18: warning: symbol UPDATE_SYM redeclared sql_yacc.yy:5169.11-5174.11: warning: unused value: $2 sql_yacc.yy:5208.11-5220.11: warning: unused value: $5 sql_yacc.yy:5221.11-5234.11: warning: unused value: $5 conflicts: 249 shift/reduce "unused value: $2" correspond to the $$=$1 assignment in the 1st {} block in table_ref -> join_table {} {}, which does not procude a result ($$) for the rule but an intermediate $2 value for the action instead. "unused value: $5" are similar, with $$ assignments in {} actions blocks which are not for the final reduce. mysql-test/r/sp.result: New test case for Bug#21462 mysql-test/t/sp.test: New test case for Bug#21462 sql/sql_yacc.yy: "CALL p;" syntax for calling a stored procedure Fixed bison 2.2 warnings.
-
- 08 Oct, 2006 3 commits
- 06 Oct, 2006 9 commits
-
-
unknown authored
into mysql.com:/home/svoj/devel/mysql/BUG22937/mysql-5.0-engines sql/ha_myisammrg.cc: Manual merge.
-
unknown authored
into mysql.com:/home/svoj/devel/mysql/BUG22937/mysql-4.1-engines
-
unknown authored
This is addition to fix for bug21617. Valgrind reports an error when opening merge table that has underlying tables with less indexes than in a merge table itself. Copy at most min(file->keys, table->key_parts) elements from rec_per_key array. This fixes problems when merge table and subtables have different number of keys. sql/ha_myisammrg.cc: Copy at most min(file->keys, table->key_parts) elements from rec_per_key array. This fixes problems when merge table and subtables have different number of keys.
-
unknown authored
into mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-5.0-engines mysql-test/r/ndb_update.result: Auto merged mysql-test/t/ndb_update.test: Auto merged
-
unknown authored
-
unknown authored
Note: bug#21726 does not directly apply to 4.1, as it doesn't have stored procedures. However, 4.1 had some bugs that were fixed in 5.0 by the patch for bug#21726, and this patch is a backport of those fixes. Namely, in 4.1 it fixes: - LAST_INSERT_ID(expr) didn't return value of expr (4.1 specific). - LAST_INSERT_ID() could return the value generated by current statement if the call happens after the generation, like in CREATE TABLE t1 (i INT AUTO_INCREMENT PRIMARY KEY, j INT); INSERT INTO t1 VALUES (NULL, 0), (NULL, LAST_INSERT_ID()); - Redundant binary log LAST_INSERT_ID_EVENTs could be generated. mysql-test/r/rpl_insert_id.result: Add result for bug#21726: Incorrect result with multiple invocations of LAST_INSERT_ID. mysql-test/t/rpl_insert_id.test: Add test case for bug#21726: Incorrect result with multiple invocations of LAST_INSERT_ID. sql/item_func.cc: Add implementation of Item_func_last_insert_id::fix_fields(), where we set THD::last_insert_id_used when statement calls LAST_INSERT_ID(). In Item_func_last_insert_id::val_int(), return THD::current_insert_id if called like LAST_INSERT_ID(), otherwise return value of argument if called like LAST_INSERT_ID(expr). sql/item_func.h: Add declaration of Item_func_last_insert_id::fix_fields(). sql/log_event.cc: Do not set THD::last_insert_id_used on LAST_INSERT_ID_EVENT. Though we know the statement will call LAST_INSERT_ID(), it wasn't called yet. sql/set_var.cc: In sys_var_last_insert_id::value_ptr(), set THD::last_insert_id_used, and return THD::current_insert_id for @@LAST_INSERT_ID. sql/sql_class.h: Update comments. Remove THD::insert_id(), as it has lost its purpose now. sql/sql_insert.cc: Now it is OK to read THD::last_insert_id directly. sql/sql_load.cc: Now it is OK to read THD::last_insert_id directly. sql/sql_parse.cc: In mysql_execute_command(), remember THD::last_insert_id (first generated value of the previous statement) in THD::current_insert_id, which then will be returned for LAST_INSERT_ID() and @@LAST_INSERT_ID. sql/sql_select.cc: If "IS NULL" is replaced with "= <LAST_INSERT_ID>", use right value, which is THD::current_insert_id, and also set THD::last_insert_id_used to issue binary log LAST_INSERT_ID_EVENT. sql/sql_update.cc: Now it is OK to read THD::last_insert_id directly. tests/mysql_client_test.c: Add test case for bug#21726: Incorrect result with multiple invocations of LAST_INSERT_ID.
-
unknown authored
-
unknown authored
into mysql.com:/home/svoj/devel/mysql/BUG10974/mysql-5.0-engines BitKeeper/deleted/.del-errmsg.txt~f96b7055cac394e: Auto merged mysql-test/r/merge.result: Manual merge.
-
unknown authored
-
- 05 Oct, 2006 4 commits
-
-
unknown authored
Stop guardian and all the rest of threads before shutdown in case of an error server-tools/instance-manager/instance_map.cc: flush_instances shouldn't reinit guardian, if it failed to load info about them server-tools/instance-manager/manager.cc: On error we should 1) stop guardian 2) terminate all other threads and exit
-
unknown authored
into mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-5.0-engines mysql-test/r/ndb_update.result: Auto merged mysql-test/t/ndb_update.test: Auto merged sql/sql_update.cc: Manual merge.
-
unknown authored
into mysql.com:/home/svoj/devel/mysql/BUG21381/mysql-4.1-engines
-
unknown authored
Though this is not storage engine specific problem, I was able to repeat this problem with BDB and NDB engines only. That was the reason to add a test case into ndb_update.test. As a result different bad things could happen. BDB has removed duplicate rows which is not expected. NDB returns an error. For multi table update notify storage engine about UPDATE IGNORE as it is done in single table UPDATE. mysql-test/r/ndb_update.result: A test case for bug#21381. mysql-test/t/ndb_update.test: A test case for bug#21381. sql/sql_update.cc: For multi table update notify storage engine about UPDATE IGNORE as it is done in single table UPDATE.
-