An error occurred fetching the project authors.
- 03 Sep, 2007 1 commit
-
-
gluh@mysql.com/eagle.(none) authored
Use view db name as thread default database, in order to ensure that the view is parsed and prepared correctly.
-
- 29 Jul, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
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.
-
- 28 Jul, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
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.
-
- 21 Jul, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
Additional test case fix for bug #29338.
-
- 19 Jul, 2007 1 commit
-
-
gshchepa/uchum@gleb.loc authored
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).
-
- 05 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
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.
-
- 04 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
'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.
-
- 27 Jun, 2007 1 commit
-
-
msvensson@pilot.(none) authored
-
- 01 Jun, 2007 1 commit
-
-
kostja@bodhi.(none) authored
-
- 29 May, 2007 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
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.
-
- 27 Apr, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
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.
-
- 25 Apr, 2007 1 commit
-
-
df@pippilotta.erinye.com authored
-
- 12 Apr, 2007 1 commit
-
-
anozdrin/alik@ibm. authored
of CHAR variable too great.
-
- 27 Mar, 2007 2 commits
-
-
anozdrin/alik@alik.opbmk authored
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.
-
thek@kpdesk.mysql.com authored
- 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.
-
- 22 Mar, 2007 1 commit
-
-
aelkin/elkin@andrepl.(none) authored
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.
-
- 16 Mar, 2007 1 commit
-
-
Kristofer.Pettersson@naruto. authored
- 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.
-
- 14 Mar, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
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.
-
- 07 Mar, 2007 1 commit
-
-
evgen@moonbone.local authored
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.
-
- 06 Mar, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
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.
-
- 19 Feb, 2007 1 commit
-
-
kaa@polly.local authored
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"
-
- 14 Dec, 2006 1 commit
-
-
kaa@polly.local authored
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.
-
- 11 Dec, 2006 1 commit
-
-
kostja@bodhi.local authored
on altered table" and Bug#19733 "Repeated alter, or repeated create/drop, fails"
-
- 14 Nov, 2006 1 commit
-
-
andrey@example.com authored
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
-
- 19 Oct, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
This patch reverts a change introduced by Bug 6951, which incorrectly set thd->abort_on_warning for stored procedures. As per internal discussions about the SQL_MODE=TRADITIONAL, the correct behavior is to *not* abort on warnings even inside an INSERT/UPDATE trigger. Tests for Stored Procedures, Stored Functions, Triggers involving SQL_MODE have been included or revised, to reflect the intended behavior. (reposting approved patch, to work around source control issues, no review needed)
-
- 09 Oct, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
The syntax of the CALL statement, to invoke a stored procedure, has been changed to make the use of parenthesis optional in the argument list. With this change, "CALL p;" is equivalent to "CALL p();". While the SQL spec does not explicitely mandate this syntax, supporting it is needed for practical reasons, for integration with JDBC / ODBC connectors. Also, warnings in the sql/sql_yacc.yy file, which were not reported by Bison 2.1 but are now reported by Bison 2.2, have been fixed. The warning found were: bison -y -p MYSQL -d --debug --verbose sql_yacc.yy sql_yacc.yy:653.9-18: warning: symbol UNLOCK_SYM redeclared sql_yacc.yy:656.9-17: warning: symbol UNTIL_SYM redeclared sql_yacc.yy:658.9-18: warning: symbol UPDATE_SYM redeclared sql_yacc.yy:5169.11-5174.11: warning: unused value: $2 sql_yacc.yy:5208.11-5220.11: warning: unused value: $5 sql_yacc.yy:5221.11-5234.11: warning: unused value: $5 conflicts: 249 shift/reduce "unused value: $2" correspond to the $$=$1 assignment in the 1st {} block in table_ref -> join_table {} {}, which does not procude a result ($$) for the rule but an intermediate $2 value for the action instead. "unused value: $5" are similar, with $$ assignments in {} actions blocks which are not for the final reduce.
-
- 04 Oct, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
Update tests and result files after running with new mysqltest that better detects problems with test files
-
- 29 Sep, 2006 1 commit
-
-
dlenev@mockturtle.local authored
-
- 28 Sep, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
- Disable warnings when creating the "innodb" tables if it works anyway. - Move test that are really innodb dependent to innodb_mysql
-
- 27 Sep, 2006 1 commit
-
-
andrey@example.com authored
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.
-
- 16 Sep, 2006 1 commit
-
-
igor@rurik.mysql.com authored
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.)
-
- 12 Sep, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
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.
-
- 07 Sep, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
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.
-
- 24 Aug, 2006 2 commits
-
-
andrey@example.com authored
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.
-
anozdrin/alik@alik. authored
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.
-
- 23 Aug, 2006 2 commits
-
-
anozdrin/alik@alik. authored
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.
-
malff/marcsql@weblab.(none) authored
Implemented code review comments Test cleanup
-
- 03 Aug, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
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.
-
- 27 Jul, 2006 1 commit
-
-
anozdrin/alik@booka. authored
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.
-
- 25 Jul, 2006 1 commit
-
-
evgen@moonbone.local authored
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.
-