An error occurred fetching the project authors.
- 14 Jul, 2008 1 commit
-
-
Marc Alff authored
build) The crash was caused by freeing the internal parser stack during the parser execution. This occured only for complex stored procedures, after reallocating the parser stack using my_yyoverflow(), with the following C call stack: - MYSQLparse() - any rule calling sp_head::restore_lex() - lex_end() - x_free(lex->yacc_yyss), xfree(lex->yacc_yyvs) The root cause is the implementation of stored procedures, which breaks the assumption from 4.1 that there is only one LEX structure per parser call. The solution is to separate the LEX structure into: - attributes that represent a statement (the current LEX structure), - attributes that relate to the syntax parser itself (Yacc_state), so that parsing multiple statements in stored programs can create multiple LEX structures while not changing the unique Yacc_state. Now, Yacc_state and the existing Lex_input_stream are aggregated into Parser_state, a structure that represent the complete state of the (Lexical + Syntax) parser.
-
- 04 Sep, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
-
- 12 Jul, 2007 1 commit
-
-
kostja@bodhi.(none) authored
causes full table lock on innodb table. Also fixes Bug#28502 Triggers that update another innodb table will block on X lock unnecessarily (duplciate). Code review fixes. Both bugs' synopses are misleading: InnoDB table is not X locked. The statements, however, cannot proceed concurrently, but this happens due to lock conflicts for tables used in triggers, not for the InnoDB table. If a user had an InnoDB table, and two triggers, AFTER UPDATE and AFTER INSERT, competing for different resources (e.g. two distinct MyISAM tables), then these two triggers would not be able to execute concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would not be able to run concurrently. The problem had other side-effects (see respective bug reports). This behavior was a consequence of a shortcoming of the pre-locking algorithm, which would not distinguish between different DML operations (e.g. INSERT and DELETE) and pre-lock all the tables that are used by any trigger defined on the subject table. The idea of the fix is to extend the pre-locking algorithm to keep track, for each table, what DML operation it is used for and not load triggers that are known to never be fired.
-
- 18 Jun, 2007 1 commit
-
-
anozdrin/alik@ibm. authored
-
- 11 May, 2007 1 commit
-
-
dlenev@mockturtle.local authored
Bug #20662 "Infinite loop in CREATE TABLE IF NOT EXISTS ... SELECT with locked tables" Bug #20903 "Crash when using CREATE TABLE .. SELECT and triggers" Bug #24738 "CREATE TABLE ... SELECT is not isolated properly" Bug #24508 "Inconsistent results of CREATE TABLE ... SELECT when temporary table exists" Deadlock occured when one tried to execute CREATE TABLE IF NOT EXISTS ... SELECT statement under LOCK TABLES which held read lock on target table. Attempt to execute the same statement for already existing target table with triggers caused server crashes. Also concurrent execution of CREATE TABLE ... SELECT statement and other statements involving target table suffered from various races (some of which might've led to deadlocks). Finally, attempt to execute CREATE TABLE ... SELECT in case when a temporary table with same name was already present led to the insertion of data into this temporary table and creation of empty non-temporary table. All above problems stemmed from the old implementation of CREATE TABLE ... SELECT in which we created, opened and locked target table without any special protection in a separate step and not with the rest of tables used by this statement. This underminded deadlock-avoidance approach used in server and created window for races. It also excluded target table from prelocking causing problems with trigger execution. The patch solves these problems by implementing new approach to handling of CREATE TABLE ... SELECT for base tables. We try to open and lock table to be created at the same time as the rest of tables used by this statement. If such table does not exist at this moment we create and place in the table cache special placeholder for it which prevents its creation or any other usage by other threads. We still use old approach for creation of temporary tables. Also note that we decided to postpone introduction of some tests for concurrent behaviour of CREATE TABLE ... SELECT till 5.1. The main reason for this is absence in 5.0 ability to set @@debug variable at runtime, which can be circumvented only by using several test files with individual .opt files. Since the latter is likely to slowdown test-suite unnecessary we chose not to push this tests into 5.0, but run them manually for this version and later push their optimized version into 5.1
-
- 24 Apr, 2007 1 commit
-
-
malff/marcsql@weblab.(none) authored
The issue found with bug 25411 is due to the function skip_rear_comments() which damages the source code while implementing a work around. The root cause of the problem is in the lexical analyser, which does not process special comments properly. For special comments like : [1] aaa /*!50000 bbb */ ccc since 5.0 is a version older that the current code, the parser is in lining the content of the special comment, so that the query to process is [2] aaa bbb ccc However, the text of the query captured when processing a stored procedure, stored function or trigger (or event in 5.1), can be after rebuilding it: [3] aaa bbb */ ccc which is wrong. To fix bug 25411 properly, the lexical analyser needs to return [2] when in lining special comments. In order to implement this, some preliminary cleanup is required in the code, which is implemented by this patch. Before this change, the structure named LEX (or st_lex) contains attributes that belong to lexical analysis, as well as attributes that represents the abstract syntax tree (AST) of a statement. Creating a new LEX structure for each statements (which makes sense for the AST part) also re-initialized the lexical analysis phase each time, which is conceptually wrong. With this patch, the previous st_lex structure has been split in two: - st_lex represents the Abstract Syntax Tree for a statement. The name "lex" has not been changed to avoid a bigger impact in the code base. - class lex_input_stream represents the internal state of the lexical analyser, which by definition should *not* be reinitialized when parsing multiple statements from the same input stream. This change is a pre-requisite for bug 25411, since the implementation of lex_input_stream will later improve to deal properly with special comments, and this processing can not be done with the current implementation of sp_head::reset_lex and sp_head::restore_lex, which interfere with the lexer. This change set alone does not fix bug 25411.
-
- 07 Mar, 2007 1 commit
-
-
kostja@bodhi.local authored
fixes). The legend: on a replication slave, in case a trigger creation was filtered out because of application of replicate-do-table/ replicate-ignore-table rule, the parsed definition of a trigger was not cleaned up properly. LEX::sphead member was left around and leaked memory. Until the actual implementation of support of replicate-ignore-table rules for triggers by the patch for Bug 24478 it was never the case that "case SQLCOM_CREATE_TRIGGER" was not executed once a trigger was parsed, so the deletion of lex->sphead there worked and the memory did not leak. The fix: The real cause of the bug is that there is no 1 or 2 places where we can clean up the main LEX after parse. And the reason we can not have just one or two places where we clean up the LEX is asymmetric behaviour of MYSQLparse in case of success or error. One of the root causes of this behaviour is the code in Item::Item() constructor. There, a newly created item adds itself to THD::free_list - a single-linked list of Items used in a statement. Yuck. This code is unaware that we may have more than one statement active at a time, and always assumes that the free_list of the current statement is located in THD::free_list. One day we need to be able to explicitly allocate an item in a given Query_arena. Thus, when parsing a definition of a stored procedure, like CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END; we actually need to reset THD::mem_root, THD::free_list and THD::lex to parse the nested procedure statement (SELECT *). The actual reset and restore is implemented in semantic actions attached to sp_proc_stmt grammar rule. The problem is that in case of a parsing error inside a nested statement Bison generated parser would abort immediately, without executing the restore part of the semantic action. This would leave THD in an in-the-middle-of-parsing state. This is why we couldn't have had a single place where we clean up the LEX after MYSQLparse - in case of an error we needed to do a clean up immediately, in case of success a clean up could have been delayed. This left the door open for a memory leak. One of the following possibilities were considered when working on a fix: - patch the replication logic to do the clean up. Rejected as breaks module borders, replication code should not need to know the gory details of clean up procedure after CREATE TRIGGER. - wrap MYSQLparse with a function that would do a clean up. Rejected as ideally we should fix the problem when it happens, not adjust for it outside of the problematic code. - make sure MYSQLparse cleans up after itself by invoking the clean up functionality in the appropriate places before return. Implemented in this patch. - use %destructor rule for sp_proc_stmt to restore THD - cleaner than the prevoius approach, but rejected because needs a careful analysis of the side effects, and this patch is for 5.0, and long term we need to use the next alternative anyway - make sure that sp_proc_stmt doesn't juggle with THD - this is a large work that will affect many modules. Cleanup: move main_lex and main_mem_root from Statement to its only two descendants Prepared_statement and THD. This ensures that when a Statement instance was created for purposes of statement backup, we do not involve LEX constructor/destructor, which is fairly expensive. In order to track that the transformation produces equivalent functionality please check the respective constructors and destructors of Statement, Prepared_statement and THD - these members were used only there. This cleanup is unrelated to the patch.
-
- 26 Feb, 2007 1 commit
-
-
bar@mysql.com authored
Problem: DROP TRIGGER was not properly handled in combination with slave filters, which made replication stop Fix: loading table name before checking slave filters when dropping a trigger.
-
- 23 Dec, 2006 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
Changed header to GPL version 2 only
-
- 14 Dec, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
- Removed not used variables and functions - Added #ifdef around code that is not used - Renamed variables and functions to avoid conflicts - Removed some not used arguments Fixed some class/struct warnings in ndb Added define IS_LONGDATA() to simplify code in libmysql.c I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
-
- 30 Nov, 2006 1 commit
-
-
monty@mysql.com/narttu.mysql.fi authored
Fixed compiler warnings (detected by VC++): - Removed not used variables - Added casts - Fixed wrong assignments to bool - Fixed wrong calls with bool arguments - Added missing argument to store(longlong), which caused wrong store method to be called.
-
- 13 Nov, 2006 1 commit
-
-
malff/marcsql@weblab.(none) authored
This change set implements the DROP TRIGGER IF EXISTS functionality. This fix is considered a bug and not a feature, because without it, there is no known method to write a database creation script that can create a trigger without failing, when executed on a database that may or may not contain already a trigger of the same name. Implementing this functionality closes an orthogonality gap between triggers and stored procedures / stored functions (which do support the DROP IF EXISTS syntax). In sql_trigger.cc, in mysql_create_or_drop_trigger, the code has been reordered to: - perform the tests that do not depend on the file system (access()), - get the locks (wait_if_global_read_lock, LOCK_open) - call access() - perform the operation - write to the binlog - unlock (LOCK_open, start_waiting_global_read_lock) This is to ensure that all the code that depends on the presence of the trigger file is executed in the same critical section, and prevents race conditions similar to the case fixed by Bug 14262 : - thread 1 executes DROP TRIGGER IF EXISTS, access() returns a failure - thread 2 executes CREATE TRIGGER - thread 2 logs CREATE TRIGGER - thread 1 logs DROP TRIGGER IF EXISTS The patch itself is based on code contributed by the MySQL community, under the terms of the Contributor License Agreement (See Bug 18161).
-
- 20 Oct, 2006 1 commit
-
-
dlenev@mockturtle.local authored
warnings in sql_trigger.cc and sql_view.cc". According to the current version of C++ standard offsetof() macro can't be used for non-POD types. So warnings were emitted when we tried to use this macro for TABLE_LIST and Table_triggers_list classes. Note that despite of these warnings it was probably safe thing to do. This fix tries to circumvent this limitation by implementing custom version of offsetof() macro to be used with these classes. This hack should go away once we will refactor File_parser class. Alternative approaches such as disabling this warning for sql_trigger.cc/sql_view.cc or for the whole server were considered less explicit. Also I was unable to find a way to disable particular warning for particular _part_ of file in GCC.
-
- 03 Oct, 2006 1 commit
-
-
cmiller@zippy.cornsilk.net authored
(race cond) It was possible for one thread to interrupt a Data Definition Language statement and thereby get messages to the binlog out of order. Consider: Connection 1: Drop Foo x Connection 2: Create or replace Foo x Connection 2: Log "Create or replace Foo x" Connection 1: Log "Drop Foo x" Local end would have Foo x, but the replicated slaves would not. The fix for this is to wrap all DDL and logging of a kind in the same mutex. Since we already use mutexes for the various parts of altering the server, this only entails moving the logging events down close to the action, inside the mutex protection.
-
- 21 Sep, 2006 1 commit
-
-
dlenev@mockturtle.local authored
this key does not stop" (version for 5.0 only). UPDATE statement which WHERE clause used key and which invoked trigger that modified field in this key worked indefinetely. This problem occured because in cases when UPDATE statement was executed in update-on-the-fly mode (in which row is updated right during evaluation of select for WHERE clause) the new version of the row became visible to select representing WHERE clause and was updated again and again. We already solve this problem for UPDATE statements which does not invoke triggers by detecting the fact that we are going to update field in key used for scanning and performing update in two steps, during the first step we gather information about the rows to be updated and then doing actual updates. We also do this for MULTI-UPDATE and in its case we even detect situation when such fields are updated in triggers (actually we simply assume that we always update fields used in key if we have before update trigger). The fix simply extends this check which is done in check_if_key_used()/ QUICK_SELECT_I::check_if_keys_used() routine/method in such way that it also detects cases when field used in key is updated in trigger. As nice side-effect we have more precise and thus more optimal perfomance-wise check for the MULTI-UPDATE. Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to better reflect that boolean predicate. Note that this check is implemented in much more elegant way in 5.1
-
- 24 Aug, 2006 1 commit
-
-
anozdrin/alik@alik. authored
Changed trigger-handling code so that there will be the one place for generate statement string for replication log and for trigger file.
-
- 27 Jul, 2006 1 commit
-
-
anozdrin/alik@booka. authored
can be not replicable. Now CREATE statements for writing in the binlog are created as follows: - the beginning of the statement is re-created; - the rest of the statement is copied from the original query. The problem appears when there is a version-specific comment (produced by mysqldump), started in the re-created part of the statement and closed in the copied part -- there is closing comment-parenthesis, but there is no opening one. The proper fix could be to re-create original statement, but we can not implement it in 5.0. So, for 5.0 the fix is just to cut closing comment-parenthesis. This technique is also used for SHOW CREATE PROCEDURE statement (so we are able to reuse existing code).
-
- 13 Jul, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
context. Routine arguments were evaluated in the security context of the routine itself, not in the caller's context. The bug is fixed the following way: - Item_func_sp::find_and_check_access() has been split into two functions: Item_func_sp::find_and_check_access() itself only finds the function and check that the caller have EXECUTE privilege on it. New function set_routine_security_ctx() changes security context for SUID routines and checks that definer have EXECUTE privilege too. - new function sp_head::execute_trigger() is called from Table_triggers_list::process_triggers() instead of sp_head::execute_function(), and is effectively just as the sp_head::execute_function() is, with all non-trigger related code removed, and added trigger-specific security context switch. - call to Item_func_sp::find_and_check_access() stays outside of sp_head::execute_function(), and there is a code in sql_parse.cc before the call to sp_head::execute_procedure() that checks that the caller have EXECUTE privilege, but both sp_head::execute_function() and sp_head::execute_procedure() call set_routine_security_ctx() after evaluating their parameters, and restore the context after the body is executed.
-
- 01 Jul, 2006 1 commit
-
-
dlenev@mysql.com authored
NDB table". SQL-layer was not marking fields which were used in triggers as such. As result these fields were not always properly retrieved/stored by handler layer. So one might got wrong values or lost changes in triggers for NDB, Federated and possibly InnoDB tables. This fix solves the problem by marking fields used in triggers appropriately. Also this patch contains the following cleanup of ha_ndbcluster code: We no longer rely on reading LEX::sql_command value in handler in order to determine if we can enable optimization which allows us to handle REPLACE statement in more efficient way by doing replaces directly in write_row() method without reporting error to SQL-layer. Instead we rely on SQL-layer informing us whether this optimization applicable by calling handler::extra() method with HA_EXTRA_WRITE_CAN_REPLACE flag. As result we no longer apply this optimzation in cases when it should not be used (e.g. if we have on delete triggers on table) and use in some additional cases when it is applicable (e.g. for LOAD DATA REPLACE). Finally this patch includes fix for bug#20728 "REPLACE does not work correctly for NDB table with PK and unique index". This was yet another problem which was caused by improper field mark-up. During row replacement fields which weren't explicity used in REPLACE statement were not marked as fields to be saved (updated) so they have retained values from old row version. The fix is to mark all table fields as set for REPLACE statement. Note that in 5.1 we already solve this problem by notifying handler that it should save values from all fields only in case when real replacement happens.
-
- 28 Jun, 2006 2 commits
-
-
kroki@mysql.com authored
It was hard to distinguish case, when one was unable to create trigger on the table because trigger with same action time and event already existed for this table, from the case, when one tried to create trigger with name which was already occupied by some other trigger, since in both these cases we emitted ER_TRG_ALREADY_EXISTS error and message. Now we emit ER_NOT_SUPPORTED_YET error with appropriate additional message in the first case. There is no sense in introducing separate error for this situation since we plan to get rid of this limitation eventually.
-
jimw@mysql.com authored
Bug #18361: Triggers on mysql.user table cause server crash Because they do not work, we do not allow creating triggers on tables within the 'mysql' schema. (They may be made to work and re-enabled at some later date, but not in 5.0 or 5.1.)
-
- 26 Jun, 2006 2 commits
-
-
konstantin@mysql.com authored
Bug#19022 "Memory bug when switching db during trigger execution" Bug#17199 "Problem when view calls function from another database." Bug#18444 "Fully qualified stored function names don't work correctly in SELECT statements" Documentation note: this patch introduces a change in behaviour of prepared statements. This patch adds a few new invariants with regard to how THD::db should be used. These invariants should be preserved in future: - one should never refer to THD::db by pointer and always make a deep copy (strmake, strdup) - one should never compare two databases by pointer, but use strncmp or my_strncasecmp - TABLE_LIST object table->db should be always initialized in the parser or by creator of the object. For prepared statements it means that if the current database is changed after a statement is prepared, the database that was current at prepare remains active. This also means that you can not prepare a statement that implicitly refers to the current database if the latter is not set. This is not documented, and therefore needs documentation. This is NOT a change in behavior for almost all SQL statements except: - ALTER TABLE t1 RENAME t2 - OPTIMIZE TABLE t1 - ANALYZE TABLE t1 - TRUNCATE TABLE t1 -- until this patch t1 or t2 could be evaluated at the first execution of prepared statement. CURRENT_DATABASE() still works OK and is evaluated at every execution of prepared statement. Note, that in stored routines this is not an issue as the default database is the database of the stored procedure and "use" statement is prohibited in stored routines. This patch makes obsolete the use of check_db_used (it was never used in the old code too) and all other places that check for table->db and assign it from THD::db if it's NULL, except the parser. How this patch was created: THD::{db,db_length} were replaced with a LEX_STRING, THD::db. All the places that refer to THD::{db,db_length} were manually checked and: - if the place uses thd->db by pointer, it was fixed to make a deep copy - if a place compared two db pointers, it was fixed to compare them by value (via strcmp/my_strcasecmp, whatever was approproate) Then this intermediate patch was used to write a smaller patch that does the same thing but without a rename. TODO in 5.1: - remove check_db_used - deploy THD::set_db in mysql_change_db See also comments to individual files.
-
ingo@mysql.com authored
Bug#17294 - INSERT DELAYED puting an \n before data Bug#16611 - INSERT DELAYED corrupts data Bug#13707 - Server crash with INSERT DELAYED on MyISAM table Combined as Bug#16218. INSERT DELAYED crashed in 5.0 on a table with a varchar that could be NULL and was created pre-5.0 (Bugs 16218 and 13707). INSERT DELAYED corrupted data in 5.0 on a table with varchar fields that was created pre-5.0 (Bugs 17294 and 16611). In case of INSERT DELAYED the open table is copied from the delayed insert thread to be able to create a record for the queue. When copying the fields, a method was used that did convert old varchar to new varchar fields and did not set up some pointers into the record buffer of the table. The field conversion was guilty for the misinterpretation of the record contents by the delayed insert thread. The wrong pointer setup was guilty for the crashes. For Bug 13707 (Server crash with INSERT DELAYED on MyISAM table) I fixed the above mentioned method to set up one of the pointers. For Bug 16218 I set up the other pointers too. But when looking at the corruptions I got aware that converting the field type was totally wrong for INSERT DELAYED. The copied table is used to create a record that is to be sent to the delayed insert thread. Of course it can interpret the record correctly only if all field types are the same in both table objects. So I revoked the fix for Bug 13707 and changed the new_field() method so that it can suppress conversions. No test case as this is a migration problem. One needs to create a table with 4.x and use it with 5.x. I added two test scripts to the bug report.
-
- 27 Mar, 2006 1 commit
-
-
anozdrin@mysql.com authored
in older version. The problem is that TRN-files created in "old" versions contain junk in trigger_table field, which is not acceptable in "new" versions.
-
- 24 Mar, 2006 1 commit
-
-
dlenev@mysql.com authored
triggers". Applying ALTER/OPTIMIZE/REPAIR TABLE statements to transactional table or to table of any type on Windows caused disappearance of its triggers. Bug was introduced in 5.0.19 by my fix for bug #13525 "Rename table does not keep info of triggers" (see comment for sql_table.cc for more info). .
-
- 10 Mar, 2006 1 commit
-
-
brian@zim.(none) authored
This patch does 1) fix my build breakage 2) Complete the removal of all symbols which could clash with another parser.
-
- 04 Mar, 2006 1 commit
-
-
dlenev@mysql.com authored
qualified subject table" which was introduced during work on bug #13525 "Rename table does not keep info of triggers". The bug was caused by the fact that during reconstruction of CREATE TRIGGER statement stored in .TRG file which happened during RENAME TABLE we damaged trigger definition in case when it contained fully qualified name of subject table (see comment for sql_yacc.yy for more info).
-
- 02 Mar, 2006 1 commit
-
-
anozdrin@mysql.com authored
The idea is to add DEFINER-clause in CREATE PROCEDURE and CREATE FUNCTION statements. Almost all support of definer in stored routines had been already done before this patch. NOTE: this patch changes behaviour of dumping stored routines in mysqldump. Before this patch, mysqldump did not dump DEFINER-clause for stored routines and this was documented behaviour. In order to get full information about stored routines, one should have dumped mysql.proc table. This patch changes this behaviour, so that DEFINER-clause is dumped. Since DEFINER-clause is not supported in CREATE PROCEDURE | FUNCTION statements before this patch, the clause is covered by additional version-specific comments.
-
- 01 Mar, 2006 1 commit
-
-
anozdrin@mysql.com authored
The idea of the fix is to extend support of non-SUID triggers for backward compatibility. Formerly non-SUID triggers were appeared when "new" server is being started against "old" database. Now, they are also created when "new" slave receives updates from "old" master.
-
- 24 Feb, 2006 1 commit
-
-
dlenev@mysql.com authored
Let us transfer triggers associated with table when we rename it (but only if we are not changing database to which table belongs, in the latter case we will emit error).
-
- 24 Jan, 2006 1 commit
-
-
anozdrin@mysql.com authored
- BUG#15166: Wrong update permissions required to execute triggers - BUG#15196: Wrong select permission required to execute triggers The idea of the fix is to check necessary privileges in Item_trigger_field::fix_fields(), instead of having "special variables" technique. To achieve this, we should pass to an Item_trigger_field instance a flag, which will indicate the usage/access type of this trigger variable.
-
- 10 Jan, 2006 1 commit
-
-
anozdrin@mysql.com authored
There are two main idea of this fix: - introduce a common function for server and client to split user value (<user name>@<host name>) into user name and host name parts; - dump DEFINER clause in correct format in mysqldump.
-
- 06 Jan, 2006 1 commit
-
-
monty@mysql.com authored
-
- 05 Jan, 2006 1 commit
-
-
monty@mysql.com authored
- Fixed tests - Optimized new code - Fixed some unlikely core dumps - Better bug fixes for: - #14397 - OPTIMIZE TABLE with an open HANDLER causes a crash - #14850 (ERROR 1062 when a quering a view using a Group By on a column that can be null
-
- 21 Dec, 2005 1 commit
-
-
knielsen@mysql.com authored
Fix: make explicit conversion to non-constant string (char *). Backported from 5.1 changeset 1.1968 05/12/19 17:36:20 kent@mysql.com +2 -0
-
- 11 Dec, 2005 1 commit
-
-
dlenev@mysql.com authored
Now when we create or drop trigger we check that both trigger name and trigger table always have database part specified. Thus we give an error if it they are not specified explicitly or implicitly via current database.
-
- 07 Dec, 2005 1 commit
-
-
anozdrin@mysql.com authored
according to the standard. The idea is to use Field-classes to implement stored routines variables. Also, we should provide facade to Item-hierarchy by Item_field class (it is necessary, since SRVs take part in expressions). The patch fixes the following bugs: - BUG#8702: Stored Procedures: No Error/Warning shown for inappropriate data type matching; - BUG#8768: Functions: For any unsigned data type, -ve values can be passed and returned; - BUG#8769: Functions: For Int datatypes, out of range values can be passed and returned; - BUG#9078: STORED PROCDURE: Decimal digits are not displayed when we use DECIMAL datatype; - BUG#9572: Stored procedures: variable type declarations ignored; - BUG#12903: upper function does not work inside a function; - BUG#13705: parameters to stored procedures are not verified; - BUG#13808: ENUM type stored procedure parameter accepts non-enumerated data; - BUG#13909: Varchar Stored Procedure Parameter always BINARY string (ignores CHARACTER SET); - BUG#14161: Stored procedure cannot retrieve bigint unsigned; - BUG#14188: BINARY variables have no 0x00 padding; - BUG#15148: Stored procedure variables accept non-scalar values;
-
- 23 Nov, 2005 1 commit
-
-
bell@sanja.is.com.ua authored
-
- 22 Nov, 2005 1 commit
-
-
bell@sanja.is.com.ua authored
if inner routine has more local variables than outer one, and one of its last variables was used as argument to NOT operator". THD::spcont was non-0 when we were parsing stored routine/trigger definition during execution of another stored routine. This confused methods of Item_splocal and forced them use wrong runtime context. Fix ensures that we always have THD::spcont equal to zero during routine/trigger body parsing. This also allows to avoid problems with errors which occur during parsing and SQL exception handlers.
-
- 20 Nov, 2005 1 commit
-
-
bell@sanja.is.com.ua authored
Bad examples of usage of a string with its length fixed. The incorrect length in the trigger file configuration descriptor fixed (BUG#14090). A hook for unknown keys added to the parser to support old .TRG files.
-