mariadb

Commit Graph

Author	SHA1	Message	Date
unknown	fac190a28b	Bug#27747 database metadata doesn't return sufficient column default info added get_field_default_value() function which obtains default value from the field (used in store_create_info() & get_schema_column_record() functions) mysql-test/r/alter_table.result: result fix mysql-test/r/create.result: result fix mysql-test/r/ctype_collate.result: result fix mysql-test/r/ctype_recoding.result: result fix mysql-test/r/default.result: result fix mysql-test/r/gis.result: result fix mysql-test/r/grant.result: result fix mysql-test/r/information_schema.result: result fix mysql-test/r/key.result: result fix mysql-test/r/mysql.result: result fix mysql-test/r/ps_1general.result: result fix mysql-test/r/show_check.result: result fix mysql-test/r/sp.result: result fix mysql-test/r/type_enum.result: result fix mysql-test/r/type_ranges.result: result fix mysql-test/t/information_schema.test: test case	18 years ago
unknown	ee0b7d895d	Bug#29408 Cannot find view in columns table if the selection contains a function Use view db name as thread default database, in order to ensure that the view is parsed and prepared correctly. mysql-test/r/sp.result: test result mysql-test/t/sp.test: test case sql/sql_parse.cc: copy thd->db_length to table_list->db_length sql/sql_view.cc: Use view db name as thread default database, in order to ensure that the view is parsed and prepared correctly.	18 years ago
unknown	3d5440505c	Test case for Bug#13675: DATETIME/DATE type in store proc param seems to be converted as varbinary. The bug has been already fixed. This CS just adds a test case for it. mysql-test/r/sp.result: Update result file. mysql-test/t/sp.test: Test case for BUG#13675.	18 years ago
unknown	8b265ffcc1	Cleanup created procedures in sp.test mysql-test/r/sp.result: Cleanup created procedures mysql-test/t/sp.test: Cleanup created procedures	19 years ago
unknown	33fc4ad4e1	Fixed bug #30120 . SP with local variables with non-ASCII names crashed the server. The server replaces SP local variable names with NAME_CONST calls when putting statements into the binary log. It used UTF8-encoded item names as variable names for the replacement inside NAME_CONST calls. However, statement string may be encoded by any known character set by the SET NAMES statement. The server used byte length of UTF8-encoded names to increment the position in the query string that led to array index overrun. sql/item.cc: Fixed bug #30120. The Item_splocal class constructor has been modified to accept new parameter `len_in_q': the byte length of variable name in the query string. sql/item.h: Fixed bug #30120. The Item_splocal class has been modified to keep new field `len_in_query': the byte length of variable name in the query string. sql/sp_head.cc: Fixed bug #30120. The subst_spvars function has been modified to increment position in the query string by the lengths of not encoded variable names instead of byte length of names encoded to UTF-8. sql/sql_yacc.yy: Fixed bug #30120. The simple_ident rule action has been modified to pass the byte length of the local variable name token to the Item_splocal object constructor. mysql-test/t/sp.test: Updated test case for bug #30120. mysql-test/r/sp.result: Updated test case for bug #30120.	19 years ago
unknown	90c5621d6c	Fixed bug #29834 . Using view columns by their names during an execution of a prepared SELECT statement or a SELECT statement inside a SP caused a memory leak. sql/sql_base.cc: Fixed bug #29834. The find_field_in_view function has been modified to use the execution memory root for the Item_direct_view_ref objects allocation at non-first executions of a PS/SP instead of the statement memory. mysql-test/t/sp.test: Updated test case for bug #29834. mysql-test/r/sp.result: Updated test case for bug #29834.	19 years ago
unknown	9cad4f08db	sp.test, sp.result: Additional test case fix for bug #29338. mysql-test/t/sp.test: Additional test case fix for bug #29338. mysql-test/r/sp.result: Additional test case fix for bug #29338.	19 years ago
unknown	36f1e4848c	Fixed bug #29338 . Optimization of queries with DETERMINISTIC functions in the WHERE clause was not effective: sequential scan was always used. Now a SF with the DETERMINISTIC flags is treated as constant when it's arguments are constants (or a SF doesn't has arguments). sql/item_func.h: Fixed bug #29338. The Item_func_sp::used_tables has been removed (virtual Item_func::used_tables function is enough). The virtual Item_func_sp::update_used_tables function has been added. sql/item_func.cc: Fixed bug #29338. The Item_func_sp::update_used_tables and the Item_func_sp::fix_field functions have been modified to take into account the DETERMINISTIC flag of SF definition. mysql-test/r/sp.result: Updated test case for bug #29338. mysql-test/t/sp.test: Updated test case for bug #29338.	19 years ago
unknown	e8966deecc	A fix and a test case for Bug#29050 Creation of a legal stored procedure fails if a database is not selected prior. The problem manifested itself when a user tried to create a routine that had non-fully-qualified identifiers in its bodies and there was no current database selected. This is a regression introduced by the fix for Bug 19022: The patch for Bug 19022 changes the code to always produce a warning if we can't resolve the current database in the parser. In this case this was not necessary, since even though the produced parsed tree was incorrect, we never re-use sphead that was obtained at first parsing of CREATE PROCEDURE. The sphead that is anyhow used is always obtained through db_load_routine, and there we change the current database to sphead->m_db before calling yyparse. The idea of the fix is to resolve the current database directly using lex->sphead->m_db member when parsing a stored routine body, when such is present. This patch removes the need to reset the current database when loading a trigger or routine definition into SP cache. The redundant code will be removed in 5.1. mysql-test/r/sp.result: Update test results (Bug#29050) mysql-test/r/trigger.result: Update results. mysql-test/t/sp.test: Add a test case for Bug#29050 mysql-test/t/trigger.test: Fix wrong behavior covered with tests. sql/sql_lex.cc: Implement st_lex::copy_db_to(). sql/sql_lex.h: Declare st_lex::copy_db_to(). sql/sql_parse.cc: Use st_lex::copy_db_to() in add_table_to_list, rather than THD::copy_db_to(). The former will use the database of the sphead, if we're parsing a stored routine, not the default database in THD. The default database is needed to initialize tables->db when the database part was not explicitly specified in the identifier. sql/sql_yacc.yy: Use st_lex::copy_db_to() in the parser, rather than THD::copy_db_to(). The former will use the database of the sphead, if we're parsing a stored routine, not the default database in THD.	19 years ago
unknown	b1ec3b534d	A fix and a teset case for Bug#28551 The warning 'No database selected' is reported when calling stored procedures Remove the offending warning introduced by the fix for Bug 25082 This minimal patch relies on the intrinsic knowledge of the fact that mysql_change_db is never called with 'force_switch' set to TRUE when such a warning may be needed: * every stored routine belongs to a database (unlike, e.g., a user defined function, which does not), so if we're activating the database of a stored routine, it can never be NULL. Therefore, this branch is never called for activation. * if we're restoring the 'old' current database after routine execution is complete, we should not issue a warning, since it's OK to call a routine without having previously selected the current database. TODO: 'force_switch' is an ambiguous flag, since we do not actually have to 'force' the switch in case of stored routines at all. When we activate the routine's database, we should perform all the checks as in case of 'use db', and so we already do (in this case 'force_switch' is unused). When we load a routine into cache, we should not use mysql_change_db at all, since there it's enough to call thd->reset_db(). We do it this way for triggers, but code for routines is different (wrongly). TODO: bugs are lurking in replication, since it bypasses mysql_change_db and calls thd->[re_]set_db to set the current database. The latter does not change thd->db_charset, thd->sctx->db_access and thd->variables.collation_database (and this may have nasty side effects). These todo items are to be addressed in a separate patch, if at all. mysql-test/r/sp.result: Update results (Bug#28551) mysql-test/t/sp.test: Add a test case (Bug#28551) sql/sp.cc: Remove an obsolete comment. Replace a check with an assert. sql/sql_db.cc: Remove the offending warning introduced by the fix for Bug 25082 This minimal patch relies on the intrinsic knowledge of the fact that mysql_change_db is never called with 'force_switch' set to TRUE when such a warning may be needed.	19 years ago
unknown	55c765925d	BUG#26976 - Missing table in merge not noted in related error msg + SHOW CREATE TABLE fails Underlying table names, that merge engine fails to open were not reported. With this fix CHECK TABLE issued against merge table reports all underlying table names that it fails to open. Other statements are unaffected, that is underlying table names are not included into error message. This fix doesn't solve SHOW CREATE TABLE issue. myisammrg/myrg_def.h: Added myrg_print_wrong_table declaration. myisammrg/myrg_open.c: If HA_OPEN_FOR_REPAIR is passed to merge engine open function, report names of tables that we fail to open. mysql-test/r/backup.result: Updated test result. mysql-test/r/key_cache.result: Updated test result - removed duplicate error. mysql-test/r/lock.result: Updated test result - added summary row. mysql-test/r/merge.result: A test case for BUG#26976. mysql-test/r/preload.result: Updated test result - removed duplicate error, added summary row. mysql-test/r/ps.result: Updated test result - removed duplicate error, added summary row. mysql-test/r/repair.result: Updated test result - removed duplicate error, added summary row. mysql-test/r/rpl_failed_optimize.result: Updated test result - removed duplicate error, added summary row. mysql-test/r/sp.result: Updated test result - removed duplicate error, added summary row. mysql-test/r/view.result: Updated test result - removed duplicate error, added summary row. mysql-test/t/merge.test: A test case for BUG#26976. sql/ha_myisam.cc: Do not report same error twice. sql/ha_myisammrg.cc: If HA_OPEN_FOR_REPAIR is passed to merge engine open function, report names of tables that we fail to open. Added dummy ha_myisammrg::check to not confuse users with "not implemented" error in case all underlying tables are fine. sql/ha_myisammrg.h: Added ha_myisammrg::check declaration. sql/share/errmsg.txt: Added ER_ADMIN_WRONG_MRG_TABLE errno. It is used instead of ER_WRONG_MRG_TABLE in case HA_OPEN_FOR_REPAIR is passed to merge engine handler open function. sql/sql_error.cc: warning_level_* are now public. It is required by mysql_admin_table to report message level. sql/sql_error.h: warning_level_* are now public. It is required by mysql_admin_table to report message level. sql/sql_table.cc: Reorder mysql_admin_table arguments to meet it's definition. Report errors that are pending in thd->warn_list as results of admin function.	19 years ago
unknown	d8cd88cd2a	Fix some mysqltest warnings. mysql-test/r/sp.result: Update results. mysql-test/t/mysql.test: Fix a typo. mysql-test/t/mysqltest.test: Fix a typo. mysql-test/t/order_by.test: Fix a typo. mysql-test/t/row.test: Remove an unsupported command. mysql-test/t/sp.test: Fix a typo. mysql-test/t/subselect3.test: Fix mysqltest warnings - now it warns when sees some suspicious -- comment	19 years ago
unknown	4e9cef545c	Bug #28492 : subselect returns LONG in >5.0.24a and LONGLONG in <=5.0.24a Integer values with 10 digits may or may not fit into an int column (e.g. 2147483647 vs 6147483647). Thus when creating a temp table column for such an int we must use bigint instead. Fixed to use bigint. Also subsituted a "magic number" with a named constant. mysql-test/r/analyse.result: Bug #28492: Adjusted the results after having fixed the bug mysql-test/r/metadata.result: Bug #28492: test case mysql-test/r/olap.result: Bug #28492: Adjusted the results after having fixed the bug mysql-test/r/sp.result: Bug #28492: Adjusted the results after having fixed the bug mysql-test/r/view.result: Bug #28492: Adjusted the results after having fixed the bug mysql-test/t/metadata.test: Bug #28492: test case sql/field.h: Bug #28492: Replaced a magic number with a constant sql/sql_select.cc: Bug #28492: Treat integers with 10 and more digits as bigint.	19 years ago
unknown	9e06efb45c	Bug #28605 : SHOW CREATE VIEW with views using stored_procedures no longer showing SP names. SHOW CREATE VIEW uses Item::print() methods to reconstruct the statement text from the parse tree. The print() method for stored procedure calls needs allocate space to print the function's quoted name. It was incorrectly calculating the length of the buffer needed (was too short). Fixed to reflect the actual space needed. mysql-test/r/sp.result: Bug #28605: test case mysql-test/t/sp.test: Bug #28605: test case sql/item_func.cc: Bug #28605: fixed the string length calculation	19 years ago
unknown	1700feaa02	Bug#21513 (SP having body starting with quoted label rendered unusable) Before this fix, the parser would sometime change where a token starts by altering Lex_input_string::tok_start, which later confused the code in sql_yacc.yy that needs to capture the source code of a SQL statement, like to represent the body of a stored procedure. This line of code in sql_lex.cc : case MY_LEX_USER_VARIABLE_DELIMITER: lip->tok_start= lip->ptr; // Skip first ` would <skip the first back quote> ... and cause the bug reported. In general, the responsibility of sql_lex.cc is to find where token are in the SQL text, but is not to make up fake or incomplete tokens. With a quoted label like `my_label`, the token starts on the first quote. Extracting the token value should not change that (it did). With this fix, the lexical analysis has been cleaned up to not change lip->tok_start (in the case found for this bug). The functions get_token() and get_quoted_token() now have an extra parameters, used when some characters from the beginning of the token need to be skipped when extracting a token value, like when extracting 'AB' from '0xAB', for example, for a HEX_NUM token. This exposed a bad assumption in Item_hex_string and Item_bin_string, which has been fixed: The assumption was that the string given, 'AB', was in fact preceded in memory by '0x', which might be false (it can be preceded by "x'" and followed by "'" -- or not be preceded by valid memory at all) If a name is needed for Item_hex_string or Item_bin_string, the name is taken from the original and true source code ('0xAB'), and assigned in the select_item rule, instead of relying on assumptions related to how memory is used. mysql-test/r/sp.result: Lex_input_stream::tok_start must point at the real start of a token. mysql-test/t/sp.test: Lex_input_stream::tok_start must point at the real start of a token. sql/item.cc: Lex_input_stream::tok_start must point at the real start of a token. sql/sql_lex.cc: Lex_input_stream::tok_start must point at the real start of a token. sql/sql_yacc.yy: Lex_input_stream::tok_start must point at the real start of a token.	19 years ago
unknown	dc98df13b6	Test case for BUG#5274: Stored procedure crash if length of CHAR variable too great. mysql-test/r/sp.result: Update result file. mysql-test/t/sp.test: Add test case for BUG#5274.	19 years ago
unknown	6a594ffd18	Fix for BUG#25082: default database change on trigger execution breaks replication. When a stored routine is executed, we switch current database to the database, in which the routine has been created. When the stored routine finishes, we switch back to the original database. The problem was that if the original database does not exist (anymore) after routine execution, we raised an error. The fix is to report a warning, and switch to the NULL database. mysql-test/r/sp.result: Updated result file. mysql-test/t/sp.test: Added test case for BUG#25082. sql/mysql_priv.h: 1. Change mysql_change_db() prototype; 2. Polishing. sql/sp.cc: Polishing. sql/sp_head.cc: Polishing. sql/sql_db.cc: 1. Polishing. 2. Fix mysql_change_db(). sql/sql_parse.cc: Polishing. sql/sql_show.cc: Polishing.	19 years ago
unknown	e4dcf4e39c	Corrected error in test case: - 1.84e+15 converted to unsigned bigint should be 18400000000000000000 < 18446744073709551615. - The test will still fail on windows, and is extracted into a new bug report.	19 years ago
unknown	df3a48ea43	Bug #27354 stored function in where condition was always treated as const Possible problems: function call could be eliminated from where class and only be evaluated once; function can be evaluated during table and item setup phase which could cause side effects not to be registered in binlog. Fixed with introducing func_item_sp::used_tables() returning the correct table_map constant. mysql-test/r/sp.result: results changed mysql-test/t/sp.test: regression test demonstrating that function's returns match where condition of the top-level query table. sql/item_func.h: private used_tables() method returning the correct table_bit with meaning the item is not a constant	19 years ago
unknown	ffc605aad5	Bug#20777 Function w BIGINT UNSIGNED shows diff. behaviour with and without --ps-protocol - Stored procedures returning unsinged values returns signed values if text protocol is used. The reason is that the stored proceedure item Item_func_sp wasn't initializing the member variables properly based on the information contained in the associated result field. - The patch is to upon field-item association, ::fix_fields, initialize the member variables in appropriate order. - Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR. This is changed to return the type of the actual result field. - Member function name sp_result_field was refactored to the more appropriate init_result_field. - Member function name find_and_check_access was refactored to sp_check_access. mysql-test/r/sp.result: - Added test mysql-test/t/sp.test: - Added test sql/item_func.cc: Bug#20777 Function w BIGINT UNSIGNED shows diff. behaviour with and without --ps-protocol - Stored procedures returning unsinged values returns signed values if text protocol is used. The reason is that the stored proceedure item Item_func_sp wasn't initializing the member variables properly based on the information contained in the associated result field. - The patch is to upon field-item association, ::fix_fields, initialize the member variables in appropriate order. - Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR. This is changed to to return the type of the actual result field. - Member function name sp_result_field was refactored to the more appropriate init_result_field. - Member function name find_and_check_access was refactored to sp_check_access. sql/item_func.h: Bug#20777 Function w BIGINT UNSIGNED shows diff. behaviour with and without --ps-protocol - Stored procedures returning unsinged values returns signed values if text protocol is used. The reason is that the stored proceedure item Item_func_sp wasn't initializing the member variables properly based on the information contained in the associated result field. - The patch is to upon field-item association, ::fix_fields, initialize the member variables in appropriate order. - Field type of an Item_func_sp was hard coded to MYSQL_TYPE_VARCHAR. This is changed to to return the type of the actual result field. - Member function name sp_result_field was refactored to the more appropriate init_result_field. - Member function name find_and_check_access was refactored to sp_check_access.	19 years ago
unknown	79344c7b67	Bug#26503 (Illegal SQL exception handler code causes the server to crash) Before this fix, the parser would accept illegal code in SQL exceptions handlers, that later causes the runtime to crash when executing the code, due to memory violations in the exception handler stack. The root cause of the problem is instructions within an exception handler that jumps to code located outside of the handler. This is illegal according to the SQL 2003 standard, since labels located outside the handler are not supposed to be visible (they are "out of scope"), so any instruction that jumps to these labels, like ITERATE or LEAVE, should not parse. The section of the standard that is relevant for this is : SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003) section 13.1 <compound statement>, syntax rule 4 <quote> The scope of the <beginning label> is CS excluding every <SQL schema statement> contained in CS and excluding every <local handler declaration list> contained in CS. <beginning label> shall not be equivalent to any other <beginning label>s within that scope. </quote> With this fix, the C++ class sp_pcontext, which represent the "parsing context" tree (a.k.a symbol table) of a stored procedure, has been changed as follows: - constructors have been cleaned up, so that only building a root node for the tree is public; building nodes inside a tree is not public. - a new member, m_label_scope, indicates if a given syntactic context belongs to a DECLARE HANDLER block, - label resolution, in the method find_label(), has been changed to implement the restriction of scope regarding labels used in a compound statement. The actions in the parser, when parsing the body of a SQL exception handler, have been changed as follows: - the implementation of an exception handler (DECLARE HANDLER) now creates explicitly a new sp_pcontext, to isolate the code inside the handler from the containing compound statement context. - registering exception handlers as a result occurs in the parent context, see the rule sp_hcond_element - the code in sp_hcond_list has been cleaned up, to avoid code duplication In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h have been removed, since they are unused and broken by design (as seen with Bug 19194 (Right recursion in parser for CASE causes excessive stack usage, limitation), representing a stack in a single flag is not possible. Tests in sp-error have been added to show that illegal constructs are now rejected. Tests in sp have been added for code coverage, to show that ITERATE or LEAVE statements are legal when jumping to a label in scope, inside the body of an exception handler. mysql-test/r/sp-error.result: SQL Exception handlers define a parsing context for label resolution. mysql-test/r/sp.result: SQL Exception handlers define a parsing context for label resolution. mysql-test/t/sp-error.test: SQL Exception handlers define a parsing context for label resolution. mysql-test/t/sp.test: SQL Exception handlers define a parsing context for label resolution. sql/sp_head.cc: Minor cleanup sql/sp_head.h: Minor cleanup sql/sp_pcontext.cc: SQL Exception handlers define a parsing context for label resolution. sql/sp_pcontext.h: SQL Exception handlers define a parsing context for label resolution. sql/sql_yacc.yy: SQL Exception handlers define a parsing context for label resolution.	19 years ago
unknown	11b533b8be	Bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. For built-in functions like sqrt() function names are hard-coded and can be compared by pointer. But this isn't the case for a used-defined stored functions - names there are dynamical and should be compared as strings. Now the Item_func::eq() function employs my_strcasecmp() function to compare used-defined stored functions names. mysql-test/t/sp.test: Added a test case for bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. mysql-test/r/sp.result: Added a test case for bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. sql/item_func.cc: Bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. Now the Item_func::eq() function employs my_strcasecmp() function to compare used-defined stored functions names.	19 years ago
unknown	266a7fff52	Bug#8407 (Stored functions/triggers ignore exception handler) Bug 18914 (Calling certain SPs from triggers fail) Bug 20713 (Functions will not not continue for SQLSTATE VALUE '42S02') Bug 21825 (Incorrect message error deleting records in a table with a trigger for inserting) Bug 22580 (DROP TABLE in nested stored procedure causes strange dependency error) Bug 25345 (Cursors from Functions) This fix resolves a long standing issue originally reported with bug 8407, which affect the behavior of Stored Procedures, Stored Functions and Trigger in many different ways, causing symptoms reported by all the bugs listed. In all cases, the root cause of the problem traces back to 8407 and how the server locks tables involved with sub statements. Prior to this fix, the implementation of stored routines would: - compute the transitive closure of all the tables referenced by a top level statement - open and lock all the tables involved - execute the top level statement "transitive closure of tables" means collecting: - all the tables, - all the stored functions, - all the views, - all the table triggers - all the stored procedures involved, and recursively inspect these objects definition to find more references to more objects, until the list of every object referenced does not grow any more. This mechanism is known as "pre-locking" tables before execution. The motivation for locking all the tables (possibly) used at once is to prevent dead locks. One problem with this approach is that, if the execution path the code really takes during runtime does not use a given table, and if the table is missing, the server would not execute the statement. This in particular has a major impact on triggers, since a missing table referenced by an update/delete trigger would prevent an insert trigger to run. Another problem is that stored routines might define SQL exception handlers to deal with missing tables, but the server implementation would never give user code a chance to execute this logic, since the routine is never executed when a missing table cause the pre-locking code to fail. With this fix, the internal implementation of the pre-locking code has been relaxed of some constraints, so that failure to open a table does not necessarily prevent execution of a stored routine. In particular, the pre-locking mechanism is now behaving as follows: 1) the first step, to compute the transitive closure of all the tables possibly referenced by a statement, is unchanged. 2) the next step, which is to open all the tables involved, only attempts to open the tables added by the pre-locking code, but silently fails without reporting any error or invoking any exception handler is the table is not present. This is achieved by trapping internal errors with Prelock_error_handler 3) the locking step only locks tables that were successfully opened. 4) when executing sub statements, the list of tables used by each statements is evaluated as before. The tables needed by the sub statement are expected to be already opened and locked. Statement referencing tables that were not opened in step 2) will fail to find the table in the open list, and only at this point will execution of the user code fail. 5) when a runtime exception is raised at 4), the instruction continuation destination (the next instruction to execute in case of SQL continue handlers) is evaluated. This is achieved with sp_instr::exec_open_and_lock_tables() 6) if a user exception handler is present in the stored routine, that handler is invoked as usual, so that ER_NO_SUCH_TABLE exceptions can be trapped by stored routines. If no handler exists, then the runtime execution will fail as expected. With all these changes, a side effect is that view security is impacted, in two different ways. First, a view defined as "select stored_function()", where the stored function references a table that may not exist, is considered valid. The rationale is that, because the stored function might trap exceptions during execution and still return a valid result, there is no way to decide when the view is created if a missing table really cause the view to be invalid. Secondly, testing for existence of tables is now done later during execution. View security, which consist of trapping errors and return a generic ER_VIEW_INVALID (to prevent disclosing information) was only implemented at very specific phases covering opening tables, but not covering the runtime execution. Because of this existing limitation, errors that were previously trapped and converted into ER_VIEW_INVALID are not trapped, causing table names to be reported to the user. This change is exposing an existing problem, which is independent and will be resolved separately. mysql-test/r/information_schema_db.result: Revised the pre-locking code implementation, aligned the tests. mysql-test/r/sp-error.result: Revised the pre-locking code implementation, aligned the tests. mysql-test/r/sp.result: Revised the pre-locking code implementation, aligned the tests. mysql-test/r/trigger.result: Revised the pre-locking code implementation, aligned the tests. mysql-test/r/view.result: Revised the pre-locking code implementation, aligned the tests. mysql-test/t/sp-error.test: Revised the pre-locking code implementation, aligned the tests. mysql-test/t/sp.test: Revised the pre-locking code implementation, aligned the tests. mysql-test/t/trigger.test: Revised the pre-locking code implementation, aligned the tests. sql/lock.cc: table->placeholder now checks for schema_table sql/mysqld.cc: my_message_sql(): invoke internal exception handlers sql/sp_head.cc: exec_open_and_lock_tables(): open and lock tables, or return the continuation destination of this instruction sql/sp_head.h: exec_open_and_lock_tables(): open and lock tables, or return the continuation destination of this instruction sql/sql_base.cc: Prelock_error_handler: delay open table errors until execution sql/sql_class.cc: THD: add internal error handler, as an exception mechanism. sql/sql_class.h: THD: add internal error handler, as an exception mechanism. sql/sql_update.cc: table->placeholder now checks for schema_table sql/table.cc: st_table_list::hide_view_error(): masked more errors for view security sql/table.h: table->placeholder now checks for schema_table, and unopened tables	19 years ago
unknown	db36a2aa5d	Bug#18743: Several test cases fails if "classic" configuration in 5.0 The problem happened because those tests were using "cp932" and "ucs2" without checking whether these character sets are available. This fix moves test parts to make character set specific parts be tested only if they are: - some parts were moved to "ctype_ucs.test" and "ctype_cp932.test" - some parts were moved to the newly added tests "innodb-ucs2.test", "mysqlbinglog-cp932.test" and "sp-ucs2.test" mysql-test/r/ctype_cp932.result: Moved cp932-specific test case from mysql.test mysql-test/r/innodb.result: Moved ucs2-specific test cases to innodb-ucs2.test mysql-test/r/mysql.result: Move cp932-specific test cases to ctype_cp932.test mysql-test/r/mysqlbinlog.result: Moved cp932-specific test case to mysqlbinlog-cp932.test mysql-test/r/sp.result: Moved ucs2-specific test case to sp-ucs2.test mysql-test/t/ctype_cp932.test: Moved cp932-specific test case from mysql.test mysql-test/t/ctype_ucs2_def-master.opt: Use the comma-separated list of character sets to avoid mysql-test errors when ucs2 is not available in the server mysql-test/t/ctype_ucs2_def.test: Added requirement for ucs2 in the server mysql-test/t/innodb.test: Moved ucs2-specific test cases to innodb-ucs2.test mysql-test/t/mysql.test: Move cp932-specific test cases to ctype_cp932.test mysql-test/t/mysqlbinlog.test: Moved cp932-specific test case to mysqlbinlog-cp932.test mysql-test/t/sp.test: Moved ucs2-specific test case to sp-ucs2.test sql/mysqld.cc: Allow specifying several character sets for test purposes, to make "mysqld" start even if the character set being tested is not compiled: mysqld --default-character-set=ucs2,latin1 The first available character set will be chosen. mysql-test/r/innodb-ucs2.result: New BitKeeper file ``mysql-test/r/innodb-ucs2.result'' mysql-test/r/mysqlbinlog-cp932.result: New BitKeeper file ``mysql-test/r/mysqlbinlog-cp932.result'' mysql-test/r/sp-ucs2.result: New BitKeeper file ``mysql-test/r/sp-ucs2.result'' mysql-test/t/innodb-ucs2.test: New BitKeeper file ``mysql-test/t/innodb-ucs2.test'' mysql-test/t/mysqlbinlog-cp932.test: New BitKeeper file ``mysql-test/t/mysqlbinlog-cp932.test'' mysql-test/t/sp-ucs2.test: New BitKeeper file ``mysql-test/t/sp-ucs2.test''	19 years ago
unknown	5b71281467	Fix for bug #24117 "server crash on a FETCH with a cursor on a table which is not in the table cache" Problem: When creating a temporary field for a temporary table in create_tmp_field_from_field(), a resulting field is created as an exact copy of an original one (in Field::new_field()). However, Field_enum and Field_set contain a pointer (typelib) to memory allocated in the parent table's MEM_ROOT, which under some circumstances may be deallocated later by the time a temporary table is used. Solution: Override the new_field() method for Field_enum and Field_set and create a separate copy of the typelib structure in there. include/typelib.h: Added copy_typelib() declaration mysql-test/r/sp.result: Added a testcase for bug #24117 "server crash on a FETCH with a cursor on a table which is not in the table cache" mysql-test/t/sp.test: Added a testcase for bug #24117 "server crash on a FETCH with a cursor on a table which is not in the table cache" mysys/typelib.c: Added copy_typelib() definition sql/field.cc: Create a copy of the internal 'typelib' structure when copying Field_enum of Field_set objects. sql/field.h: Override new_field method in Field_enum (and Field_set) to copy the typelib structure.	19 years ago
unknown	a8103a89b4	Post-merge fixes for Bug#4968 "Stored procedure crash if cursor opened 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.	19 years ago
unknown	645aac545e	Fix for bug#23760 ROW_COUNT() and store procedure not owrking together The problem was that THD::row_count_func was zeroed too. It was zeroed as a fix for bug 4905 "Stored procedure doesn't clear for "Rows affected" However, the proper solution is not to zero, because THD::row_count_func has been set to -1 already in mysql_execute_command(), a later fix, which obsoletes the incorrect fix of #4095 mysql-test/r/sp.result: update result mysql-test/t/sp.test: test for bug#23760 ROW_COUNT() and store procedure not owrking together sql/sql_parse.cc: Remove zeroing for thd->row_count_func The fix for #4905 wasn't right. Now, it's ok without this zeroing because if there was an error THD::	19 years ago
unknown	5bd58f3e00	Bug#20028 (Function with select return no data) 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	19 years ago
unknown	e1e0f829e6	Bug#21462 (Stored procedures with no arguments require parenthesis) 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.	19 years ago
unknown	fcb8687ad9	Fix for bug#21311: Possible stack overrun if SP has non-latin1 name There was possible stack overrun in an edge case which handles invalid body of a SP in mysql.proc . That should be case when mysql.proc has been changed manually. Though, due to bug 21513, it can be exploited without having access to mysql.proc only being able to create a stored routine. mysql-test/r/sp.result: update result mysql-test/t/sp.test: add a test case for the bug sql/sp.cc: Fix stack overrun. This happen mostly when mysql.proc is damaged, though it's possible due to another bug which creates invalid SP body in mysql.proc (leading quote from a label being cut) to create stack overrun even without having direct access to mysql.proc	19 years ago
unknown	58e178c5cc	Fixed bug #21493 : crash for the second execution of a function containing a select statement that uses an aggregating IN subquery. Added a parameter to the function fix_prepare_information to restore correctly the having clause for the second execution. Saved andor structure of the having conditions at the proper moment before any calls of split_sum_func2 that could modify the having structure adding new Item_ref objects. (These additions, are produced not with the statement mem_root, but rather with the execution mem_root.) mysql-test/r/sp.result: Added a test case for bug #21493. mysql-test/t/sp.test: Added a test case for bug #21493. sql/sql_delete.cc: Fixed bug #21493: crash for the second execution of a function containing a select statement that uses an aggregating IN subquery. Added a parameter to the function fix_prepare_information to restore correctly the having clause for the second execution. sql/sql_insert.cc: Fixed bug #21493: crash for the second execution of a function containing a select statement that uses an aggregating IN subquery. Added a parameter to the function fix_prepare_information to restore correctly the having clause for the second execution. sql/sql_lex.cc: Fixed bug #21493: crash for the second execution of a function containing a select statement that uses an aggregating IN subquery. Added a parameter to the function fix_prepare_information to restore correctly the having clause for the second execution. sql/sql_lex.h: Fixed bug #21493: crash for the second execution of a function containing a select statement that uses an aggregating IN subquery. Added a parameter to the function fix_prepare_information to restore correctly the having clause for the second execution. sql/sql_update.cc: Fixed bug #21493: crash for the second execution of a function containing a select statement that uses an aggregating IN subquery. Added a parameter to the function fix_prepare_information to restore correctly the having clause for the second execution.	19 years ago
unknown	d4933af87e	BUG#21414: SP: Procedure undroppable, to some extent The problem was that if after FLUSH TABLES WITH READ LOCK the user issued DROP/ALTER PROCEDURE/FUNCTION the operation would fail (as expected), but after UNLOCK TABLE any attempt to execute the same operation would lead to the error 1305 "PROCEDURE/FUNCTION does not exist", and an attempt to execute any stored function will also fail. This happened because under FLUSH TABLES WITH READ LOCK we couldn't open and lock mysql.proc table for update, and this fact was erroneously remembered by setting mysql_proc_table_exists to false, so subsequent statements believed that mysql.proc doesn't exist, and thus that there are no functions and procedures in the database. As a solution, we remove mysql_proc_table_exists flag completely. The reason is that this optimization didn't work most of the time anyway. Even if open of mysql.proc failed for some reason when we were trying to call a function or a procedure, we were setting mysql_proc_table_exists back to true to force table reopen for the sake of producing the same error message (the open can fail for number of reasons). The solution could have been to remember the reason why open failed, but that's a lot of code for optimization of a rare case. Hence we simply remove this optimization. mysql-test/r/sp.result: Add result for bug#21414: SP: Procedure undroppable, to some extent. mysql-test/t/sp.test: Remove no longer relevant comment. Add test case for bug#21414: SP: Procedure undroppable, to some extent. sql/mysql_priv.h: Remove declaration of mysql_proc_table_exists. sql/sp.cc: Remove references to mysql_proc_table_exists. sql/sql_acl.cc: Remove reference to mysql_proc_table_exists.	19 years ago
unknown	ee09b41ea2	BUG#20492: Subsequent calls to stored procedure yield incorrect result if join is used For procedures with selects that use complicated joins with ON expression re-execution could erroneously ignore this ON expression, giving incorrect result. The problem was that optimized ON expression wasn't saved for re-execution. The solution is to properly save it. mysql-test/r/sp.result: Add result for bug#20492: Subsequent calls to stored procedure yield incorrect result if join is used. mysql-test/t/sp.test: Add test case for bug#20492: Subsequent calls to stored procedure yield incorrect result if join is used. sql/sql_select.cc: Save modified ON expression for re-execution.	19 years ago
unknown	807ecdf43a	Fix for bug#21416 SP: Recursion level higher than zero needed for non-recursive call The following procedure was not possible if max_sp_recursion_depth is 0 create procedure show_proc() show create procedure show_proc; Actually there is no recursive call but the limit is checked. Solved by temporarily increasing the thread's limit just before the fetch from cache and decreasing after that. mysql-test/r/sp.result: update result mysql-test/t/sp.test: Test for bug #21416 SP: Recursion level higher than zero needed for non-recursive call sql/sp.cc: Increase the max_sp_recursion_depth temporarily for SHOW CREATE PROCEDURE call. This call is in fact not recursive but is counted as such. Outcome, it will work always but if max_sp_recursion_depth is reached we are going to cache one more sp_head instance.	20 years ago
unknown	21e6836b39	Fix for BUG#16899: Possible buffer overflow in handling of DEFINER-clause User name (host name) has limit on length. The server code relies on these limits when storing the names. The problem was that sometimes these limits were not checked properly, so that could lead to buffer overflow. The fix is to check length of user/host name in parser and if string is too long, throw an error. mysql-test/r/grant.result: Updated result file. mysql-test/r/sp.result: Updated result file. mysql-test/r/trigger.result: Updated result file. mysql-test/r/view.result: Updated result file. mysql-test/t/grant.test: Added test for BUG#16899. mysql-test/t/sp.test: Added test for BUG#16899. mysql-test/t/trigger.test: Added test for BUG#16899. mysql-test/t/view.test: Added test for BUG#16899. sql/mysql_priv.h: Added prototype for new function. sql/sql_acl.cc: Remove outdated checks. sql/sql_parse.cc: Add a new function for checking string length. sql/share/errmsg.txt: Added new resources. sql/sql_yacc.yy: Check length of user/host name.	20 years ago
unknown	f96ee72fb0	Fix for BUG#16899: Possible buffer overflow in handling of DEFINER-clause User name (host name) has limit on length. The server code relies on these limits when storing the names. The problem was that sometimes these limits were not checked properly, so that could lead to buffer overflow. The fix is to check length of user/host name in parser and if string is too long, throw an error. mysql-test/r/grant.result: Updated result file. mysql-test/r/sp.result: Updated result file. mysql-test/r/trigger.result: Updated result file. mysql-test/r/view.result: Updated result file. mysql-test/t/grant.test: Added test for BUG#16899. mysql-test/t/sp.test: Added test for BUG#16899. mysql-test/t/trigger.test: Added test for BUG#16899. mysql-test/t/view.test: Added test for BUG#16899. sql/mysql_priv.h: Added prototype for new function. sql/share/errmsg.txt: Added new resources. sql/sql_acl.cc: Remove outdated checks. sql/sql_parse.cc: Add a new function for checking string length. sql/sql_yacc.yy: Check length of user/host name.	20 years ago
unknown	09e9b2f6cd	Bug#8153 (Stored procedure with subquery and continue handler, wrong result) Implemented code review comments Test cleanup sql/protocol.cc: Bug#8153 (Stored procedure with subquery and continue handler, wrong result) Implemented code review comments	20 years ago
unknown	f748b69134	Bug#8153 (Stored procedure with subquery and continue handler, wrong result) Before this fix, - a runtime error in a statement in a stored procedure with no error handlers was properly detected (as expected) - a runtime error in a statement with an error handler inherited from a non local runtime context (i.e., proc a with a handler, calling proc b) was properly detected (as expected) - a runtime error in a statement with a local error handler was executed as follows : a) the statement would succeed, regardless of the error condition, (bug) b) the error handler would be called (as expected). The root cause is that functions like my_messqge_sql would "forget" to set the thread flag thd->net.report_error to 1, because of the check involving sp_rcontext::found_handler_here(). Failure to set this flag would cause, later in the call stack, in Item_func::fix_fields() at line 190, the code to return FALSE and consider that executing the statement was successful. With this fix : - error handling code, that was duplicated in different places in the code, is now implemented in sp_rcontext::handle_error(), - handle_error() correctly sets thd->net.report_error when a handler is present, regardless of the handler location (local, or in the call stack). A test case, bug8153_subselect, has been written to demonstrate the change of behavior before and after the fix. Another test case, bug8153_function_a, as also been writen. This test has the same behavior before and after the fix. This test has been written to demonstrate that the previous expected result of procedure bug18787, was incorrect, since select no_such_function() should fail and therefore not produce a result. The incorrect result for bug18787 has the same root cause as Bug#8153, and the expected result has been adjusted. sql/mysqld.cc: Bug#8153, use sp_rcontext::handle_error() to handle errors. sql/sql_error.cc: Bug#8153, use sp_rcontext::handle_error() to handle errors. sql/protocol.cc: Bug#8153, use sp_rcontext::handle_error() to handle errors. sql/sp_rcontext.h: Bug#8153, created helper sp_rcontext::handle_error() to handle errors. sql/sp_rcontext.cc: Bug#8153, created helper sp_rcontext::handle_error() to handle errors. mysql-test/t/sp.test: Bug#8153, added test cases. mysql-test/r/sp.result: Bug#8153, added test cases, fixed expected result of bug18787.	20 years ago
unknown	3c10858474	Fix for BUG#16211: Stored function return type for strings is ignored. Fix for BUG#16676: Database CHARSET not used for stored procedures The problem in BUG#16211 is that CHARSET-clause of the return type for stored functions is just ignored. The problem in BUG#16676 is that if character set is not explicitly specified for sp-variable, the server character set is used instead of the database one. The fix has two parts: - always store CHARSET-clause of the return type along with the type definition in mysql.proc.returns column. "Always" means that CHARSET-clause is appended even if it has not been explicitly specified in CREATE FUNCTION statement (this affects BUG#16211 only). Storing CHARSET-clause if it is not specified is essential to avoid changing character set if the database character set is altered in the future. NOTE: this change is not backward compatible with the previous releases. - use database default character set if CHARSET-clause is not explicitly specified (this affects both BUG#16211 and BUG#16676). NOTE: this also breaks backward compatibility. mysql-test/r/mysqldump.result: Updated result file. mysql-test/r/sp.result: Updated result file. mysql-test/t/sp.test: Provided test cases for BUG#16211, BUG#16676. sql/mysql_priv.h: Added two convenient functions for work with databases. sql/sp.cc: 1. Add CHARSET-clause to CREATE-statement if it has been explicitly specified. 2. Polishing -- provided some comments. sql/sp_head.cc: Use database charset as default charset of sp-variable. sql/sp_head.h: Move init_sp_name() out of init_strings(). sql/sql_db.cc: Two new functions created: - load_db_opt_by_name(); - check_db_dir_existence(); sql/sql_show.cc: Eliminate duplicated code by using check_db_dir_existence() and load_db_opt_by_name() sql/sql_table.cc: Eliminate duplicated code by using check_db_dir_existence() and load_db_opt_by_name() sql/sql_yacc.yy: Call sp_head::init_sp_name() to initialize stored routine name.	20 years ago
unknown	9a63adc8fd	Fixed bug#19862: Sort with filesort by function evaluates function twice When there is no index defined filesort is used to sort the result of a query. If there is a function in the select list and the result set should be ordered by it's value then this function will be evaluated twice. First time to get the value of the sort key and second time to send its value to a user. This happens because filesort when sorts a table remembers only values of its fields but not values of functions. All functions are affected. But taking into account that SP and UDF functions can be both expensive and non-deterministic a temporary table should be used to store their results and then sort it to avoid twice SP evaluation and to get a correct result. If an expression referenced in an ORDER clause contains a SP or UDF function, force the use of a temporary table. A new Item_processor function called func_type_checker_processor is added to check whether the expression contains a function of a particular type. mysql-test/t/udf.test: Added test case for bug#19862: Sort with filesort by function evaluates function twice mysql-test/t/sp.test: Added test case for bug#19862: Sort with filesort by function evaluates function twice mysql-test/r/sp.result: Added test case for bug#19862: Sort with filesort by function evaluates function twice mysql-test/r/udf.result: Added test case for bug#19862: Sort with filesort by function evaluates function twice sql/sql_select.cc: Fixed bug#19862: Sort with filesort by function evaluates function twice If an expression referenced in an ORDER clause contains a SP or UDF function, force the use of a temporary table. sql/item_func.h: Fixed bug#19862: Sort with filesort by function evaluates function twice A new Item_processor function called func_type_checker_processor is added to check whether the expression contains a function of a particular type. sql/item.h: Fixed bug#19862: Sort with filesort by function evaluates function twice A new Item_processor function called func_type_checker_processor is added to check whether the expression contains a function of a particular type. sql/item_func.cc: Fixed bug#19862: Sort with filesort by function evaluates function twice A new Item_processor function called func_type_checker_processor is added to check whether the expression contains a function of a particular type.	20 years ago
unknown	0fa250a936	A fix and a test case for Bug#21002 "Derived table not selecting from a "real" table fails in JOINs". This is a regression caused by the fix for Bug 18444. This fix removed the assignment of empty_c_string to table->db performed in add_table_to_list, as neither me nor anyone else knew what it was there for. Now we know it and it's covered with tests: the only case when a table database name can be empty is when the table is a derived table. The fix puts the assignment back but makes it a bit more explicit. Additionally, finally drop sp.result.orig which was checked in by mistake. BitKeeper/deleted/.del-sp.result.orig: Delete: mysql-test/r/sp.result.orig mysql-test/r/derived.result: Updated result file. mysql-test/r/sp.result: Test results fixed (Bug#21002) mysql-test/t/derived.test: New error return for the case when MULTI-DELETE tries to delete from a derived table: now derived tables belong to their own db (""), and MUTLI-DELETE can't find the correspondent table for it in the DELETE list, as it can't resolve tables in different dbs by alias (See Bug#21148 for details) mysql-test/t/sp.test: Add a test case for Bug#21002 "Derived table not selecting from a "real" table fails in JOINs" sql/sp.cc: Make empty_c_string globally accessible. sql/sql_class.cc: Add empty_c_string definition. sql/sql_class.h: Add a comment for the constructor of Table_ident which is used for derived tables. Make sure this constructor also initializes the database name, not only the table name. sql/sql_parse.cc: Don't call check_db_name for empty database. Currently the only case when a table database name can be empty is when the table is a derived table. Report the right error if the database name is wrong (ER_WRONG_DB_NAME, not ER_WRONG_TABLE_NAME).	20 years ago
unknown	ca00a985a1	Bug#21013: Performance Degrades when importing data that uses Trigger and Stored Procedure The essence of the bug was that for every re-execution of stored routine or prepared statement new items for character set conversions were created, thus increasing the number of items and the time of their processing, and creating memory leak. No test case is provided since current test suite can't cover such type of bugs. mysql-test/r/sp.result: Add result for bug#21013: Performance Degrades when importing data that uses Trigger and Stored Procedure. mysql-test/t/sp.test: Add test case for bug#21013: Performance Degrades when importing data that uses Trigger and Stored Procedure. sql/item.cc: Switch arena only when in statement prepare mode. Subsequent executions will use cached item tree.	20 years ago
unknown	1e44259440	Fixed bug #19714 . DESCRIBE returned the type BIGINT for a column of a view if the column was specified by an expression over values of the type INT. E.g. for the view defined as follows: CREATE VIEW v1 SELECT COALESCE(f1,f2) FROM t1 DESCRIBE returned type BIGINT for the only column of the view if f1,f2 are columns of the INT type. At the same time DESCRIBE returned type INT for the only column of the table defined by the statement: CREATE TABLE t2 SELECT COALESCE(f1,f2) FROM t1. This inconsistency was removed by the patch. Now the code chooses between INT/BIGINT depending on the precision of the aggregated column type. Thus both DESCRIBE commands above returns type INT for v1 and t2. mysql-test/r/analyse.result: Adjusted the results after having fixed bug #19714. mysql-test/r/bigint.result: Adjusted the results after having fixed bug #19714. mysql-test/r/create.result: Adjusted the results after having fixed bug #19714. mysql-test/r/olap.result: Adjusted the results after having fixed bug #19714. mysql-test/r/ps_2myisam.result: Adjusted the results after having fixed bug #19714. mysql-test/r/ps_3innodb.result: Adjusted the results after having fixed bug #19714. mysql-test/r/ps_4heap.result: Adjusted the results after having fixed bug #19714. mysql-test/r/ps_5merge.result: Adjusted the results after having fixed bug #19714. mysql-test/r/ps_6bdb.result: Adjusted the results after having fixed bug #19714. mysql-test/r/ps_7ndb.result: Adjusted the results after having fixed bug #19714. mysql-test/r/sp.result: Adjusted the results after having fixed bug #19714. mysql-test/r/subselect.result: Adjusted the results after having fixed bug #19714. mysql-test/r/type_ranges.result: Adjusted the results after having fixed bug #19714. mysql-test/r/view.result: Added a test case for bug #19714. mysql-test/t/view.test: Added a test case for bug #19714.	20 years ago
unknown	d6bcbfbe92	A fix and a test case for 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.	20 years ago
unknown	67fd3c4a53	A fix and a test case for Bug#15217 "Using a SP cursor on a table created with PREPARE fails with weird error". More generally, re-executing a stored procedure with a complex SP cursor query could lead to a crash. The cause of the problem was that SP cursor queries were not optimized properly at first execution: their parse tree belongs to sp_instr_cpush, not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the cursor was declared, not when it was opened. This led to loss of optimization transformations performed at first execution, as sp_instr_copen saw that the query is already "EXECUTED" and therefore either not ran first-execution related blocks or wrongly rolled back the transformations caused by first-execution code. The fix is to update the state of the parsed tree only when the tree is executed, as opposed to when the instruction containing the tree is executed. Assignment if i->state is moved to reset_lex_and_exec_core. mysql-test/r/sp.result: Test results fixed (Bug#15217) mysql-test/t/sp.test: Add a test case for Bug#15217 sql/sp_head.cc: Move assignment of stmt_arena->state to reset_lex_and_exec_core	20 years ago
unknown	02bacd818d	Test case for BUG#18037: Server crash when returning system variable in stored procedures.	20 years ago
unknown	24a0b385fb	Fix for BUG#18587: Function that accepts and returns TEXT garbles data if longer than 766 chars. The problem is that a stored routine returns BLOBs to the previous caller, BLOBs are shallow-copied (i.e. only pointers to the data are copied). The fix is to also copy data of BLOBs. mysql-test/r/sp.result: Updated result file. mysql-test/t/sp.test: Added a test case for BUG#18587. sql/field_conv.cc: Do not jump to optimization if the field type is BLOB and the destination table requires copying of BLOBs. sql/item_func.cc: Request copying BLOBs for the result table.	20 years ago
unknown	4f15a043e2	Fix for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which explicitly or implicitly uses stored function gives "Table not locked" error' CREATE TABLE ... SELECT ... statement which was explicitly or implicitly (through view) using stored function gave "Table not locked" error. The actual bug resides in the current locking scheme of CREATE TABLE SELECT code, which first opens and locks tables of the SELECT statement itself, and then, having SELECT tables locked, creates the .FRM, opens the .FRM and acquires lock on it. This scheme opens a possibility for a deadlock, which was present and ignored since version 3.23 or earlier. This scheme also conflicts with the invariant of the prelocking algorithm -- no table can be open and locked while there are tables locked in prelocked mode. The patch makes an exception for this invariant when doing CREATE TABLE ... SELECT, thus extending the possibility of a deadlock to the prelocked mode. We can't supply a better fix in 5.0. mysql-test/r/sp.result: Added tests for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which explicitly or implicitly uses stored function gives "Table not locked" error' mysql-test/t/sp.test: Added tests for bugs#12472/#15137 'CREATE TABLE ... SELECT ... which explicitly or implicitly uses stored function gives "Table not locked" error' sql/mysql_priv.h: Added flag which can be passed to open_table() routine in order to ignore set of locked tables and prelocked mode. We don't need declaration of create_table_from_items() any longer as it was moved into sql_insert.cc and made static. sql/sql_base.cc: open_table(): Added flag which allows open table ignoring set of locked tables and prelocked mode. sql/sql_insert.cc: Moved create_table_from_items() from sql_table.cc to sql_insert.cc as it was not used outside of sql_insert.cc and contains code which is specific for CREATE TABLE ... SELECT. Also now when we are executing CREATE TABLE ... SELECT ... statement which SELECT part requires execution in prelocked mode we ignore set of locked tables in order to get access to the table we just have created. We probably don't want to do this if we are under real LOCK TABLES since it will widen window for deadlock too much. sql/sql_table.cc: Moved create_table_from_items() routine into sql_insert.cc, since it was not used anywhere outside of this file and contains logic which is specific for CREATE TABLE ... SELECT statement.	20 years ago
unknown	10eac46a52	Bug#15728: LAST_INSERT_ID function inside a stored function returns 0 Do not reset value of LAST_INSERT_ID() in sub-statement. mysql-test/r/rpl_insert_id.result: Add result for bug#15728. mysql-test/r/sp.result: Add result for bug#15728. mysql-test/t/rpl_insert_id.test: Add test case for bug#15728. mysql-test/t/sp.test: Add test case for bug#15728. sql/sql_class.cc: Do not reset value of LAST_INSERT_ID() in sub-statement.	20 years ago
unknown	176cd14352	Fixed BUG#18344: DROP DATABASE does not drop associated routines We must use the db key length in sp_drop_db_routines (and not the number of characters), or long db names will be truncated in the key. mysql-test/r/sp.result: Updated results for new test case (BUG#18344) mysql-test/t/sp.test: Added new test case for BUG#18344. sql/sp.cc: In sp_drop_db_routines(), give the key field's ("db") key length instead of the number of characters to index_read(), or the key packing will truncate long db names.	20 years ago

1 2 3 4 5 ...

369 Commits (0d6ec6cdc8c353af7b373df59264e7283e22edc5)