An error occurred fetching the project authors.
- 08 Feb, 2008 1 commit
-
-
unknown authored
The unsignedness of large integer user variables was not being properly preserved when feeded to prepared statements. This was happening because the unsigned flags wasn't being updated when converting the user variable is converted to a parameter. The solution is to copy the unsigned flag when converting the user variable to a parameter and take the unsigned flag into account when converting the integer to a string. mysql-test/r/binlog.result: Add test case result for Bug#33798 mysql-test/r/ps.result: Add test case result for Bug#33798 mysql-test/t/binlog.test: Add test case for Bug#33798 mysql-test/t/ps.test: Add test case for Bug#33798 sql/item.cc: Take the unsigned flag into account when converting the user variable.
-
- 10 Nov, 2007 1 commit
-
-
unknown authored
-
- 07 Nov, 2007 1 commit
-
-
unknown authored
Problem: calling non-constant argument's val_xxx() methods in the ::fix_length_and_dec() is inadmissible. Fix: call the method only for constant arguments. mysql-test/r/ps.result: Fix for bug #32137: prepared statement crash with str_to_date in update clause - test result. mysql-test/t/ps.test: Fix for bug #32137: prepared statement crash with str_to_date in update clause - test case. sql/item_timefunc.cc: Fix for bug #32137: prepared statement crash with str_to_date in update clause - call argument's val_str() only for constant items in the Item_func_str_to_date::fix_length_and_dec().
-
- 29 Aug, 2007 1 commit
-
-
unknown authored
-
- 18 May, 2007 1 commit
-
-
unknown authored
Set parameter's type to Item::DECIMAL_ITEM assigning a decimal value. mysql-test/r/ps.result: Fox for bug #28509: strange behaviour: passing a decimal value to PS - test result. mysql-test/t/ps.test: Fox for bug #28509: strange behaviour: passing a decimal value to PS - test case. sql/item.cc: Fox for bug #28509: strange behaviour: passing a decimal value to PS - set Item_param::item_type to Item::DECIMAL_ITEM in case of DECIMAL_RESULT variable. - removed redundant item_result_type assignments as it's set before.
-
- 15 May, 2007 1 commit
-
-
unknown authored
-
- 14 May, 2007 1 commit
-
-
unknown authored
statement from a UNION query with ORDER BY an expression containing RAND(). The crash happened because the global order by list in the union query was not re-initialized for execution. (Local order by lists were re-initialized though). mysql-test/r/ps.result: Added a test case for bug #27937. mysql-test/t/ps.test: Added a test case for bug #27937. sql/sql_union.cc: Fixed bug #27937: crash for the the second execution of a prepared statement from a UNION query with ORDER BY an expression containing RAND(). The crash happened because the global order by list in the union query was not re-initialized for execution. (Local order by lists were re-initialized though). Added re-initialization of the global order by list in the function st_select_lex_unit::init_prepare_fake_select_lex.
-
- 11 May, 2007 1 commit
-
-
unknown authored
by moving yet another relevant flag to it from struct LEX. mysql-test/r/ps.result: Update result. mysql-test/r/ps_1general.result: Update result. mysql-test/t/ps.test: New error code. mysql-test/t/ps_1general.test: New error code. sql/sql_lex.cc: Move stmt_prepare_mode to Lex_input_stream. sql/sql_lex.h: Move stmt_prepare_mode to class Lex_input_stream sql/sql_prepare.cc: Move stmt_prepare_mode to Lex_input_stream sql/sql_yacc.yy: Remove dead code.
-
- 01 Feb, 2007 1 commit
-
-
unknown authored
Notes: This patch doesn't fix all issues in the tree and we need jani's fix for that This patch shoud not be merged into 5.0 mysql-test/r/ps.result: result fix mysql-test/r/symlink.result: result fix mysql-test/t/ps.test: test is moved to 'symlink' test mysql-test/t/symlink.test: test from 'ps' test sql/field_conv.cc: valgrind error fix: backport from 5.0 sql/mysqld.cc: release of ssl_context vio/viosslfactories.c: release of ssl_context mysql-test/valgrind.supp: New BitKeeper file ``mysql-test/valgrind.supp'' This file is backported from 5.0, added suppressing of OpenSSL errors
-
- 23 Jan, 2007 1 commit
-
-
unknown authored
on duplicate key". INSERT ... SELECT ... ON DUPLICATE KEY UPDATE which was used in stored routine or as prepared statement and which in its ON DUPLICATE KEY clause erroneously tried to assign value to a column mentioned only in its SELECT part was properly emitting error on the first execution but succeeded on the second and following executions. Code which is responsible for name resolution of fields mentioned in UPDATE clause (e.g. see select_insert::prepare()) modifies table list and Name_resolution_context used in this process. It uses Name_resolution_context_state::save_state/restore_state() to revert these modifications. Unfortunately those two methods failed to revert properly modifications to TABLE_LIST::next_name_resolution_table and this broke name resolution process for successive executions. This patch fixes Name_resolution_context_state::save_state/restore_state() in such way that it properly handles TABLE_LIST::next_name_resolution_table. mysql-test/r/ps.result: Added test case for bug#24491 "using alias from source table in insert ... on duplicate key" mysql-test/r/sp-error.result: Added test case for bug#24491 "using alias from source table in insert ... on duplicate key" mysql-test/t/ps.test: Added test case for bug#24491 "using alias from source table in insert ... on duplicate key" mysql-test/t/sp-error.test: Added test case for bug#24491 "using alias from source table in insert ... on duplicate key" sql/item.h: Name_resolution_context::save_state/restore_state(): At the moment these methods are used only by code implementing INSERT and INSERT ... SELECT statements. This code doesn't modify 'next_name_resolution_table' member of table list element corresponding to the first table of SELECT clause (pointed by 'first_name_resolution_table'). But it modifies table list element corresponding to the target table of INSERT (pointed by 'table_list') So these methods were changed to reflect this.
-
- 19 Jan, 2007 2 commits
- 17 Jan, 2007 1 commit
-
-
unknown authored
mysql-test/r/ps.result: Update result files. mysql-test/t/ps.test: Disable result ouptut of SHOW CREATE TABLE: DATA DIRECTORY option may be present or absent from the output depending on the build otpions and the operating system, so the output is not consistent across supported platforms. sql/mysqld.cc: Remove a tricky #ifdef dependency of --use-symbolic-links on PURIFY added in 2002: DEBUG options should not influence server functionality. This backfired by producing different output of SHOW CREATE TABLE depending on the build options (see also Bug#25677 "With --skip-symbolic-links option on, DATA DIRECTORY clause is silently ignored".
-
- 16 Jan, 2007 1 commit
-
-
unknown authored
mysql-test/t/backup.test: Backport a patch for sporadically failing myisam.test (and now ps.test) from 5.0. The cause was in backup.test not cleaning up tables in mysqltest-vardir/tmp after itself. mysql-test/t/ps.test: Add additional protection against possible failure in the middle of backup.test
-
- 14 Dec, 2006 1 commit
-
-
unknown authored
Blocked evaluation of constant objects of the classes Item_func_is_null and Item_is_not_null_test at the prepare phase in the cases when the objects used subqueries. mysql-test/r/ps.result: Extended test case for bug #25027. mysql-test/t/ps.test: Extended test case for bug #25027. sql/sql_lex.cc: Returned back the assertion in st_select_lex_unit::set_limit, removed by the previous commit for this bug.
-
- 13 Dec, 2006 1 commit
-
-
unknown authored
Removed an assertion that was not valid for the cases where the query in a prepared statement contained a single-row non-correlated subquery that was used as an argument of the IS NULL predicate. mysql-test/r/ps.result: Added a test case for bug #25027. mysql-test/t/ps.test: Added a test case for bug #25027.
-
- 11 Dec, 2006 1 commit
-
-
unknown authored
on altered table" and Bug#19733 "Repeated alter, or repeated create/drop, fails" mysql-test/r/ps.result: Post-merge fixes: update results with new tests. mysql-test/r/sp.result: Post-merge fixes: update results. mysql-test/t/ps.test: Add more test cases for Bug#4968 and related. mysql-test/t/sp.test: A post-merge fix: add more testcases for Bug#4968 and related. sql/sql_insert.cc: Post-merge fixes: update comments, fix errors of the manual merge. sql/sql_lex.cc: Fix a manual merge error. sql/sql_parse.cc: Fix a few errors of the manual merge, style. sql/sql_table.cc: Post-merge fixes, fix a few errors of the manual merge, fix style. sql/sql_yacc.yy: A post-merge fix.
-
- 07 Dec, 2006 1 commit
-
-
unknown authored
Bug#4968 "Stored procedure crash if cursor opened on altered table" Bug#19733 "Repeated alter, or repeated create/drop, fails" Bug#19182 "CREATE TABLE bar (m INT) SELECT n FROM foo; doesn't work from stored procedure." Bug#6895 "Prepared Statements: ALTER TABLE DROP COLUMN does nothing" Bug#22060 "ALTER TABLE x AUTO_INCREMENT=y in SP crashes server" Test cases for bugs 4968, 19733, 6895 will be added in 5.0. Re-execution of CREATE DATABASE, CREATE TABLE and ALTER TABLE statements in stored routines or as prepared statements caused incorrect results (and crashes in versions prior to 5.0.25). In 5.1 the problem occured only for CREATE DATABASE, CREATE TABLE SELECT and CREATE TABLE with INDEX/DATA DIRECTOY options). The problem of bugs 4968, 19733, 19282 and 6895 was that functions mysql_prepare_table, mysql_create_table and mysql_alter_table were not re-execution friendly: during their operation they used to modify contents of LEX (members create_info, alter_info, key_list, create_list), thus making the LEX unusable for the next execution. In particular, these functions removed processed columns and keys from create_list, key_list and drop_list. Search the code in sql_table.cc for drop_it.remove() and similar patterns to find evidence. The fix is to supply to these functions a usable copy of each of the above structures at every re-execution of an SQL statement. To simplify memory management, LEX::key_list and LEX::create_list were added to LEX::alter_info, a fresh copy of which is created for every execution. The problem of crashing bug 22060 stemmed from the fact that the above metnioned functions were not only modifying HA_CREATE_INFO structure in LEX, but also were changing it to point to areas in volatile memory of the execution memory root. The patch solves this problem by creating and using an on-stack copy of HA_CREATE_INFO (note that code in 5.1 already creates and uses a copy of this structure in mysql_create_table()/alter_table(), but this approach didn't work well for CREATE TABLE SELECT statement). mysql-test/r/ps.result: Update test results (Bug#19182, Bug#22060) mysql-test/t/ps.test: Add a test case for Bug#19182, Bug#22060 (4.1-only parts) sql/mysql_priv.h: LEX::key_list and LEX::create_list were moved to LEX::alter_info. Update declarations to use LEX::alter_info instead of these two members. sql/sql_class.h: Replace pair<columns, keys> with an instance of Alter_info in select_create constructor. We create a new copy of Alter_info each time we re-execute SELECT .. CREATE prepared statement. sql/sql_insert.cc: Adjust to a new signature of create_table_from_items. sql/sql_lex.cc: Implement Alter_info::Alter_info that would make a "deep" copy of all definition lists (keys, columns). sql/sql_lex.h: Move key_list and create_list to class Alter_info. Implement Alter_info::Alter_info that can be used with PS and SP. sql/sql_list.h: Implement a copy constructor of class List that makes a deep copy of all list nodes. sql/sql_parse.cc: Adjust to new signatures of mysql_create_table, mysql_alter_table, select_create. Functions mysql_create_index and mysql_drop_index has become identical after initialization of alter_info was moved to the parser, and were merged. Flag enable_slow_log was not updated for SQLCOM_DROP_INDEX, which is a bug. Just like CREATE INDEX, DROP INDEX is currently done via complete table rebuild and is rightfully a slow administrative statement. sql/sql_show.cc: Adjust mysqld_show_create_db to a new signature. sql/sql_table.cc: Adjust mysql_alter_table, mysql_recreate_table, mysql_create_table, mysql_prepare_table to new signatures. sql/sql_yacc.yy: LEX::key_list and LEX::create_list moved to class Alter_info
-
- 29 Nov, 2006 1 commit
-
-
unknown authored
prepared statement and subquery. When a field of a view from an outer select is resolved the find_field_in_view function creates an Item_direct_view_ref object that references the corresponding view underlying field. After that the view_ref is marked as a dependent one. While resolving view underlying field it also get marked as a dependent one due to current_select still points to the subselect. Marking the view underlying field is wrong and lead to attaching conditions to a wrong table and thus to the wrong result of the whole statement. Now mark_select_range_as_dependent() function isn't called for fields from a view underlying table. sql/sql_base.cc: Bug#20327: Marking of a wrong field leads to a wrong result on select with view, prepared statement and subquery. Now mark_select_range_as_dependent() function isn't called for fields from a view underlying table. mysql-test/r/ps.result: Added a test case for bug#20327: Marking of a wrong field leads to a wrong result on select with view, prepared statement and subquery. mysql-test/t/ps.test: Added a test case for bug#20327: Marking of a wrong field leads to a wrong result on select with view,prepared statement and subquery.
-
- 21 Nov, 2006 2 commits
-
-
unknown authored
mysql-test/r/ps.result: Fix after manual merge: update for different error message. mysql-test/t/ps.test: Fix after manual merge: use right error codes.
-
unknown authored
Make Prepared_stmt_count a global status variable, accessible via SHOW STATUS LIKE 'Prepared_stmt_count';. Documentation should be updated. mysql-test/r/ps.result: Update result for bug#16365: Prepared Statements: DoS with too many open statements, according to bug#23159: prepared_stmt_count should be status variable. mysql-test/t/ps.test: Update test case for bug#16365: Prepared Statements: DoS with too many open statements, according to bug#23159: prepared_stmt_count should be status variable. sql/mysqld.cc: Add Prepared_stmt_count as global status variable. sql/set_var.cc: Remove prepared_stmt_count as system variable.
-
- 19 Oct, 2006 1 commit
-
-
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.
-
- 12 Oct, 2006 1 commit
-
-
unknown authored
Do not consider SHOW commands slow queries, just because they don't use proper indexes. This bug fix is not needed in 5.1, and the code changes will be null merged. However, the test cases will be propogated up to 5.1. mysql-test/t/show_check-master.opt: Rename: BitKeeper/deleted/.del-show_check-master.opt -> mysql-test/t/show_check-master.opt mysql-test/r/ps.result: Add test case for bug 19764 mysql-test/r/show_check.result: Add test case for bug 19764 mysql-test/r/union.result: Adjust test case results based on bug #19764 changes mysql-test/t/ps.test: Add test case for bug 19764 mysql-test/t/show_check.test: Add test case for bug 19764 sql/sql_parse.cc: Do not log SHOW commands as slow queries just because they don't use indexes. sql/sql_prepare.cc: Save stmt_backup.lex->orig_sql_command for use in log_slow_statement() mysql-test/t/ps-master.opt: Add log-slow-queries and --log-queries-not-using indexes, to test bug #19764
-
- 10 Oct, 2006 1 commit
-
-
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.
-
- 03 Oct, 2006 1 commit
-
-
unknown authored
- ie. backport from 5.1 - also update testcase error dected by new version mysql-test/include/show_msg.inc: BitKeeper file /home/msvensson/mysql/same_tools/my41-same_tools/mysql-test/include/show_msg.inc mysql-test/include/show_msg80.inc: BitKeeper file /home/msvensson/mysql/same_tools/my41-same_tools/mysql-test/include/show_msg80.inc BitKeeper/deleted/.del-rpl_chain_temp_table.test: Delete: mysql-test/t/rpl_chain_temp_table.test BitKeeper/deleted/.del-rpl_chain_temp_table.result: Delete: mysql-test/r/rpl_chain_temp_table.result BitKeeper/deleted/.del-rpl_failsafe.result: Delete: mysql-test/r/rpl_failsafe.result BitKeeper/deleted/.del-rpl_failsafe.test: Delete: mysql-test/t/rpl_failsafe.test BitKeeper/deleted/.del-rpl_heap.test: Delete: mysql-test/t/rpl_heap.test BitKeeper/deleted/.del-rpl_heap.result: Delete: mysql-test/r/rpl_heap.result BitKeeper/deleted/.del-rpl000018.result: Delete: mysql-test/r/rpl000018.result BitKeeper/deleted/.del-rpl000018.test: Delete: mysql-test/t/rpl000018.test client/Makefile.am: Link mysqltest with mysys/my_copy.c client/mysqltest.c: Update mysqltest to latest version mysql-test/include/have_multi_ndb.inc: Remove old syntax "@filename" in favor of "--require filename" mysql-test/include/master-slave.inc: Remove old syntax "@filename" in favor of "--require filename" mysql-test/include/ps_query.inc: Remove the comment about no output now when it does. mysql-test/r/check.result: Update output from --send mysql-test/r/connect.result: Update result file for connect test after backport form 5.1 mysql-test/r/flush.result: Update output from --send mysql-test/r/flush_block_commit.result: Update output from --send mysql-test/r/func_misc.result: Update output from --send mysql-test/r/grant2.result: Update output from --send mysql-test/r/handler.result: Update output from --send mysql-test/r/kill.result: Update output from --send mysql-test/r/lock_multi.result: Update output from --send mysql-test/r/mix_innodb_myisam_binlog.result: Update output from --send mysql-test/r/mysqltest.result: Update mysqltest.result after backport mysql-test/r/ps_2myisam.result: Update result as the output from query is now printed mysql-test/r/ps_3innodb.result: Update result as the output from query is now printed mysql-test/r/ps_4heap.result: Update result as the output from query is now printed mysql-test/r/ps_5merge.result: Update result as the output from query is now printed mysql-test/r/ps_6bdb.result: Update result as the output from query is now printed mysql-test/r/ps_7ndb.result: Update result as the output from query is now printed mysql-test/r/rename.result: Update output from --send mysql-test/r/rpl000001.result: Update output from --send mysql-test/r/rpl_error_ignored_table.result: Update output from --send mysql-test/r/rpl_master_pos_wait.result: Update output from --send mysql-test/r/subselect.result: Update result file after adding missing ; mysql-test/r/synchronization.result: Update output from --send mysql-test/r/type_blob.result: Update result file after adding missing ; mysql-test/t/connect.test: Backport test from 5.1 mysql-test/t/init_file.test: Update test so something is printed mysql-test/t/mysql_client_test.test: Update test so result is sent to file and something is printed mysql-test/t/mysqltest.test: Backport latest mysqltest.test file mysql-test/t/ps.test: Move the --replace_column statement to just before the statetement it should replace mysql-test/t/ps_1general.test: Move the --replace_column statement to just before the statetement it should replace mysql-test/t/ps_grant.test: Remove the $DB, no other test uses it mysql-test/t/rpl_flush_tables.test: Fetch $SERVER_VERSION from the db server mysql-test/t/rpl_trunc_temp.test: Remove the selection of connection master after it's been disconnected already mysql-test/t/subselect.test: Add missing ; mysql-test/t/type_blob.test: Add missing ;
-
- 27 Sep, 2006 1 commit
-
-
unknown authored
Re-execution of a parametrized prepared statement or a stored routine with a SELECT that use LEFT JOIN with second table having only one row could yield incorrect result. The problem appeared only for left joins with second table having only one row (aka const table) and equation conditions in ON or WHERE clauses that depend on the argument passed. Once the condition was false for second const table, a NULL row was created for it, and any field involved got NULL-value flag, which then was never reset. The cause of the problem was that Item_field::null_value could be set without being reset for re-execution. The solution is to reset Item_field::null_value in Item_field::cleanup(). mysql-test/r/ps.result: Add result for bug#21081: SELECT inside stored procedure returns wrong results. mysql-test/t/ps.test: Add test case for bug#21081: SELECT inside stored procedure returns wrong results. sql/item.cc: Reset Item_field::null_value flag for re-execution.
-
- 19 Sep, 2006 1 commit
-
-
unknown authored
-
- 16 Sep, 2006 1 commit
-
-
unknown authored
statement that uses an aggregating IN subquery with HAVING clause. A wrong order of the call of split_sum_func2 for the HAVING clause of the subquery and the transformation for the subquery resulted in the creation of a andor structure that could not be restored at an execution of the prepared statement. mysql-test/r/ps.result: Added a test cases for bug #22085. mysql-test/t/ps.test: Added a test cases for bug #22085.
-
- 24 Aug, 2006 1 commit
-
-
unknown authored
Changes in an item tree done by optimizer weren't properly registered and went unnoticed, which resulted in preliminary freeing of used memory. mysql-test/r/ps.result: Add result for bug#21166: Prepared statement causes signal 11 on second execution. mysql-test/t/ps.test: Add test case for bug#21166: Prepared statement causes signal 11 on second execution. sql/item.cc: Move Item::transform() and Item_default_value::transform() from item.h here and use THD::change_item_tree() instead of plain assignment. Change Item_field::set_no_const_sub() to be used with Item::walk() instead of Item::transform(). sql/item.h: Move definition of Item::transform() and Item_default_value::transform() to item.cc. Change Item::set_no_const_sub() to be used with Item::walk() instead of Item::transform(). sql/item_cmpfunc.cc: Use Item::walk() to execute Item::set_no_const_sub(). Use THD::change_item_tree() instead of plain assignment. sql/item_func.cc: Add assert and comment to Item_func::traverse_cond(). sql/item_row.cc: Use THD::change_item_tree() instead of plain assignment. sql/item_strfunc.cc: Move Item_func_make_set::transform() from item_strfunc.h here and use THD::change_item_tree() instead of plain assignment. sql/item_strfunc.h: Move definition of Item_func_make_set::transform() to item_strfunc.cc.
-
- 11 Jul, 2006 1 commit
-
-
unknown authored
when dropping/creating tables" mysql-test/r/ps.result: A post-merge fix. mysql-test/t/ps.test: A post-merge fix: all 5.0 tests should go after 4.1 tests. sql/sql_lex.cc: auxilliary -> auxiliary sql/sql_prepare.cc: auxilliary -> auxiliary sql/table.cc: Update st_table_list::reinit_before_use in 5.0 to include 5.0-specific cleanups. sql/table.h: st_table_list::reinit_before_use is public.
-
- 06 Jul, 2006 1 commit
-
-
unknown authored
dropping/creating tables". The bug could lead to a crash when multi-delete statements were prepared and used with temporary tables. The bug was caused by lack of clean-up of multi-delete tables before re-execution of a prepared statement. In a statement like DELETE t1 FROM t1, t2 WHERE ... the first table list (t1) is moved to lex->auxilliary_table_list and excluded from lex->query_tables or select_lex->tables. Thus it was unaccessible to reinit_stmt_before_use and not cleaned up before re-execution of a prepared statement. mysql-test/r/ps.result: Updated test results (Bug#19399) mysql-test/t/ps.test: A test case for Bug#19399 "Stored Procedures 'Lost Connection' when dropping/creating tables": test that multi-delete tables are cleaned up properly before re-execution. sql/sql_lex.cc: Always initialize auxilliary_table_list when we initialize the lex: this way we don't have to check that lex->sql_command equals to SQLCOM_DELETE_MULTI whenever we need to access auxilliary_table_list. In particular, in reinit_stmt_before_use we can simply check that auxilliary_table_list is not NULL and clean it up if the check returns a true value. sql/sql_prepare.cc: Move the one table clean-up functionality to a method of st_table_list. Clean up auxiliary_table_list if it's not empty. sql/table.cc: Implement st_table_list::reinit_before_use(). sql/table.h: Declare st_table_list::reinit_before_use().
-
- 26 Jun, 2006 1 commit
-
-
unknown authored
Bug#19022 "Memory bug when switching db during trigger execution" Bug#17199 "Problem when view calls function from another database." Bug#18444 "Fully qualified stored function names don't work correctly in SELECT statements" Documentation note: this patch introduces a change in behaviour of prepared statements. This patch adds a few new invariants with regard to how THD::db should be used. These invariants should be preserved in future: - one should never refer to THD::db by pointer and always make a deep copy (strmake, strdup) - one should never compare two databases by pointer, but use strncmp or my_strncasecmp - TABLE_LIST object table->db should be always initialized in the parser or by creator of the object. For prepared statements it means that if the current database is changed after a statement is prepared, the database that was current at prepare remains active. This also means that you can not prepare a statement that implicitly refers to the current database if the latter is not set. This is not documented, and therefore needs documentation. This is NOT a change in behavior for almost all SQL statements except: - ALTER TABLE t1 RENAME t2 - OPTIMIZE TABLE t1 - ANALYZE TABLE t1 - TRUNCATE TABLE t1 -- until this patch t1 or t2 could be evaluated at the first execution of prepared statement. CURRENT_DATABASE() still works OK and is evaluated at every execution of prepared statement. Note, that in stored routines this is not an issue as the default database is the database of the stored procedure and "use" statement is prohibited in stored routines. This patch makes obsolete the use of check_db_used (it was never used in the old code too) and all other places that check for table->db and assign it from THD::db if it's NULL, except the parser. How this patch was created: THD::{db,db_length} were replaced with a LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were manually checked and: - if the place uses thd->db by pointer, it was fixed to make a deep copy - if a place compared two db pointers, it was fixed to compare them by value (via strcmp/my_strcasecmp, whatever was approproate) Then this intermediate patch was used to write a smaller patch that does the same thing but without a rename. TODO in 5.1: - remove check_db_used - deploy THD::set_db in mysql_change_db See also comments to individual files. mysql-test/r/create.result: Modify the result file: a database can never be NULL. mysql-test/r/ps.result: Update test results (Bug#17199 et al) mysql-test/r/sp.result: Update test results (Bug#17199 et al) mysql-test/t/create.test: Update the id of the returned error. mysql-test/t/ps.test: Add test coverage for prepared statements and current database. In scope of work on Bug#17199 "Problem when view calls function from another database." mysql-test/t/sp.test: Add a test case for Bug#17199 "Problem when view calls function from another database." and Bug#18444 "Fully qualified stored function names don't work correctly in SELECT statements". Test a complementary problem. sql/item_strfunc.cc: Touch the code that reads thd->db (cleanup). sql/log_event.cc: While we are at it, replace direct access to thd->db with a method. Should simplify future conversion of THD::db to LEX_STRING. sql/slave.cc: While we are at it, replace direct access to thd->db with a method. Should simplify future conversion of THD::db to LEX_STRING. sql/slave.h: Remove a declaration for a method that is used only in one module. sql/sp.cc: Rewrite sp_use_new_db: this is a cleanup that I needed in order to understand this function and ensure that it has no bugs. sql/sp.h: Add a new declaration for sp_use_new_db (uses LEX_STRINGs) and a comment. sql/sp_head.cc: - drop sp_name_current_db_new - a creator of sp_name class that was used when sp_name was created for an identifier without an explicitly initialized database. Now we pass thd->db to constructor of sp_name right in the parser. - rewrite sp_head::init_strings: name->m_db is always set now - use the new variant of sp_use_new_db - we don't need to update thd->db with SP MEM_ROOT pointer anymore when parsing a stored procedure, as noone will refer to it (yes!) sql/sp_head.h: - remove unneded methods and members sql/sql_class.h: - introduce 3 THD methods to work with THD::db: .set_db to assign the current database .reset_db to reset the current database (temporarily) or set it to NULL .opt_copy_db_to - to deep-copy thd->db to a pointer if it's not NULL sql/sql_db.cc: While we are at it, replace direct access to thd->db with a method. Should simplify future conversion of THD::db to LEX_STRING. sql/sql_insert.cc: - replace checks with asserts: table_list->db must be always set in the parser. sql/sql_lex.h: - add a comment sql/sql_parse.cc: - implement the invariant described in the changeset comment. - remove juggling with lex->sphead in SQLCOM_CREATE_PROCEDURE: now db_load_routine uses its own LEX object and doesn't damage the main LEX. - add DBUG_ASSERT(0) to unused "check_db_used" sql/sql_table.cc: - replace a check with an assert (table_ident->db) sql/sql_trigger.cc: While we are at it, replace direct access to thd->db with a method. Should simplify future conversion of THD::db to LEX_STRING. sql/sql_udf.cc: - use thd->set_db instead of direct modification of to thd->db sql/sql_view.cc: - replace a check with an assert (view->db) sql/sql_yacc.yy: - make sure that we always copy table->db or name->db or ident->db or select_lex->db from thd->db if the former is not set. If thd->db is not set but is accessed, return an error. sql/tztime.cc: - be nice, never copy thd->db by pointer.
-
- 29 May, 2006 1 commit
-
-
unknown authored
-
- 25 Apr, 2006 1 commit
-
-
unknown authored
supported in SP but not in PS": just enable them in prepared statements, the supporting functionality was implemented when they were enabled in stored procedures. mysql-test/r/ps.result: Bug#19308: test results fixed. mysql-test/r/ps_1general.result: Adjust existing test cases (ANALYZE/OPTIMIZE/REPAIR are now allowed in prepared statements. mysql-test/r/sp-dynamic.result: Adjust existing test cases (ANALYZE/OPTIMIZE/REPAIR are now allowed in prepared statements. mysql-test/t/ps.test: Add a test case for Bug#19308 "REPAIR/OPTIMIZE/ANALYZE supported in SP but not in PS" mysql-test/t/ps_1general.test: Adjust existing test cases (ANALYZE/OPTIMIZE/REPAIR are now allowed in prepared statements. sql/sql_prepare.cc: Enable ANALYZE, OPTIMIZE, REPAIR in prepared statements.
-
- 12 Apr, 2006 1 commit
-
-
unknown authored
limit. mysql-test/r/ps.result: Post-merge fixes. mysql-test/t/ps.test: Post-merge fixes. sql/share/errmsg.txt: Add a new error message for max_prepared_stmt_count limit, we can do it in 5.0 sql/sql_class.cc: Post-merge fixes. sql/sql_class.h: Post-merge fixes. sql/sql_prepare.cc: Post-merge fixes.
-
- 07 Apr, 2006 2 commits
-
-
unknown authored
too many open statements". The patch adds a new global variable @@max_prepared_stmt_count. This variable limits the total number of prepared statements in the server. The default value of @@max_prepared_stmt_count is 16382. 16382 small statements (a select against 3 tables with GROUP, ORDER and LIMIT) consume 100MB of RAM. Once this limit has been reached, the server will refuse to prepare a new statement and return ER_UNKNOWN_ERROR (unfortunately, we can't add new errors to 4.1 without breaking 5.0). The limit is changeable after startup and can accept any value from 0 to 1 million. In case the new value of the limit is less than the current statement count, no new statements can be added, while the old still can be used. Additionally, the current count of prepared statements is now available through a global read-only variable @@prepared_stmt_count. mysql-test/r/ps.result: Test results fixed (a test case for Bug#16365) mysql-test/t/ps.test: A test case for Bug#16365 "Prepared Statements: DoS with too many open statements". Also fix statement leaks in other tests. sql/mysql_priv.h: Add declarations for new global variables. sql/mysqld.cc: Add definitions of max_prepared_stmt_count, prepared_stmt_count. sql/set_var.cc: Implement support for @@prepared_stmt_count and @@max_prepared_stmt_count. Currently these variables are queried without acquiring LOCK_prepared_stmt_count due to limitations of the set_var/sys_var class design. Updates are, however, protected with a lock. sql/set_var.h: New declarations to add support for @@max_prepared_stmt_count. Implement a new class, where the lock to be used when updating a variable is a parameter. sql/sql_class.cc: Add accounting of the total number of prepared statements in the server to the methods of Statement_map. sql/sql_class.h: Add accounting of the total number of prepared statements in the server to the methods of Statement_map. sql/sql_prepare.cc: Statement_map::insert will now send a message in case of an error.
-
unknown authored
gives wrong results". Implement previously missing Item_row::cleanup. The bug is not repeatable in 5.0, probably due to a coincidence: the problem is present in 5.0 as well. mysql-test/r/ps.result: Update the result file (Bug#16248) mysql-test/t/ps.test: Add a test case for Bug#16248 "WHERE (col1,col2) IN ((?,?)) gives wrong results" sql/item_row.cc: Implement Item_row::cleanup(): we should reset used_tables_cache before reexecution of a prepared statement. In case ROW arguments contain a placeholder, used_tables_cache has PARAM_TABLE bit set in statement prepare. As a result, when executing a statement, the condition push down algorithm (make_cond_for_table) would think that the WHERE clause belongs to the non-existent PARAM_TABLE and wouldn't attach the WHERE clause to any of the real tables, effectively optimizing the clause away. sql/item_row.h: Remove a never used member 'array_holder'. Add declaration for Item_row::cleanup.
-
- 28 Mar, 2006 1 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().
-
- 23 Feb, 2006 1 commit
-
-
unknown authored
fixed in 5.0). A post-review fix (Bug#13134) mysql-test/r/heap.result: Remove 'delayed' to make the test deterministic. mysql-test/r/ps.result: Remove an unneeded drop table (test case for Bug#13134) mysql-test/t/heap.test: Remove 'delayed' to make the test deterministic. mysql-test/t/ps.test: A post-review fix (Bug#13134)
-
- 21 Feb, 2006 1 commit
-
-
unknown authored
column is increasing when table is recreated with PS/SP": make use of create_field::char_length more consistent in the code. Reinit create_field::length from create_field::char_length for every execution of a prepared statement (actually fixes the bug). mysql-test/r/ps.result: Test results fixed (Bug#13134) mysql-test/t/ps.test: A test case for Bug#13134 "Length of VARCHAR() utf8 column is increasing when table is recreated with PS/SP" sql/field.cc: Move initialization of create_field::char_length to the constructor of create_field. sql/field.h: Rename chars_length to char_length (to be consistent with how this term is used throughout the rest of the code). sql/sql_parse.cc: Initialize char_length in add_field_to_list. This function effectively works as another create_field constructor. sql/sql_table.cc: Reinit length from char_length for every field in mysql_prepare_table. This is not needed if we're executing a statement for the first time, however, at subsequent executions length contains the number of bytes, not characters (as it's expected to).
-