An error occurred fetching the project authors.
- 06 Mar, 2007 2 commits
-
-
malff/marcsql@weblab.(none) authored
-
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.
-
- 22 Jan, 2007 3 commits
-
-
monty@mysql.com/narttu.mysql.fi authored
-
monty@mysql.com/narttu.mysql.fi authored
-
monty@mysql.com/narttu.mysql.fi authored
Changed error message to be compatible with old error file Added new error message for new DUP_ENTRY syntax
-
- 17 Jan, 2007 1 commit
-
-
cmiller@zippy.cornsilk.net authored
-
- 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 2 commits
-
-
kostja@bodhi.local authored
on altered table" and Bug#19733 "Repeated alter, or repeated create/drop, fails"
-
patg@radha.myhome.westell.com authored
* New result files due to new error message/error numbers * Fixed system_mysql_db tests to work with servers table * Added UTF8 charset to table defs
-
- 09 Dec, 2006 1 commit
-
-
patg@govinda.patg.net authored
Post-commit issues fixed * Test results for other tests fixed due to added error #s * Memory allocation/free issues found with running with valgrind * Fix to mysql-test-run shell script to run federated_server test (installs mysql.servers table properly)
-
- 05 Dec, 2006 2 commits
-
-
msvensson@neptunus.(none) authored
-
df@kahlann.erinye.com authored
-
- 17 Nov, 2006 1 commit
-
-
Fix tests for new behaviour: an error is thrown if a NON DETERMINISTIC stored function (SF) is called during statement-based replication (SBR).
-
- 15 Nov, 2006 3 commits
-
-
malff/marcsql@weblab.(none) authored
-
andrey@example.com authored
-
malff/marcsql@weblab.(none) authored
Bug#21025 (misleading error message when creating functions named 'x', or 'y') Bug#22619 (Spaces considered harmful) This change contains a fix to report warnings or errors, and multiple tests cases. Before this fix, name collisions between: - Native functions - User Defined Functions - Stored Functions were not systematically reported, leading to confusing behavior. I) Native / User Defined Function Before this fix, is was possible to create a UDF named "foo", with the same name as a native function "foo", but it was impossible to invoke the UDF, since the syntax "foo()" always refer to the native function. After this fix, creating a UDF fails with an error if there is a name collision with a native function. II) Native / Stored Function Before this fix, is was possible to create a SF named "db.foo", with the same name as a native function "foo", but this was confusing since the syntax "foo()" would refer to the native function. To refer to the Stored Function, the user had to use the "db.foo()" syntax. After this fix, creating a Stored Function reports a warning if there is a name collision with a native function. III) User Defined Function / Stored Function Before this fix, creating a User Defined Function "foo" and a Stored Function "db.foo" are mutually exclusive operations. Whenever the second function is created, an error is reported. However, the test suite did not cover this behavior. After this fix, the behavior is unchanged, and is now covered by test cases. Note that the code change in this patch depends on the fix for Bug 21114.
-
- 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
-
- 23 Oct, 2006 1 commit
-
-
kostja@bodhi.local authored
-
- 19 Oct, 2006 2 commits
-
-
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)
-
malff/marcsql@weblab.(none) authored
-
- 17 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.
-
- 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.
-
- 29 Sep, 2006 1 commit
-
-
dlenev@mockturtle.local authored
-
- 27 Sep, 2006 2 commits
-
-
andrey@example.com authored
-
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.
-
- 18 Sep, 2006 1 commit
-
-
gkodinov@dl145s.mysql.com authored
-
- 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.
-
- 30 Aug, 2006 1 commit
-
-
kostja@bodhi.local authored
-
- 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
-
- 14 Aug, 2006 1 commit
-
-
kostja@bodhi.local authored
-
- 10 Aug, 2006 1 commit
-
-
andrey@example.com authored
-
- 09 Aug, 2006 1 commit
-
-
andrey@lmy004. authored
create function func() returns char(10) binary ... is no more possible. This will be reenabled when bug 2676 "DECLARE can't have COLLATE clause in stored procedure" is fixed. Fix after 2nd review
-
- 04 Aug, 2006 1 commit
-
-
andrey@lmy004. 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.
-
- 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.
-