An error occurred fetching the project authors.
- 13 Nov, 2006 1 commit
-
-
holyfoot/hf@mysql.com/deer.(none) authored
-
- 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
-
- 25 Aug, 2006 1 commit
-
-
andrey@example.com authored
erroneous check Problem: Actually there were two problems in the server code. The check for SQLCOM_FLUSH in SF/Triggers were not according to the existing architecture which uses sp_get_flags_for_command() from sp_head.cc . This function was also missing a check for SQLCOM_FLUSH which has a problem combined with prelocking. This changeset fixes both of these deficiencies as well as the erroneous check in sp_head::is_not_allowed_in_function() which was a copy&paste error.
-
- 24 Aug, 2006 1 commit
-
-
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 1 commit
-
-
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.
-
- 29 Jun, 2006 1 commit
-
-
kroki@mysql.com authored
-
- 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.)
-
- 16 Jun, 2006 1 commit
-
-
dlenev@mysql.com authored
INSERT triggers". In cases when REPLACE was internally executed via update and table had on update (on delete) triggers defined we exposed the fact that such optimization used by callng on update (not calling on delete) triggers. Such behavior contradicts our documentation which describes REPLACE as INSERT with optional DELETE. This fix just disables this optimization for tables with on delete triggers. The optimization is still applied for tables which have on update but have no on delete triggers, we just don't invoke on update triggers in this case and thus don't expose information about optimization to user. Also added test coverage for values returned by ROW_COUNT() function (and thus for values returned by mysql_affected_rows()) for various forms of INSERT.
-
- 12 May, 2006 1 commit
-
-
kroki@mysql.com authored
from within triggers Add support for passing NEW.x as INOUT and OUT parameters to stored procedures. Passing NEW.x as INOUT parameter requires SELECT and UPDATE privileges on that column, and passing it as OUT parameter requires only UPDATE privilege.
-
- 19 Apr, 2006 2 commits
-
-
dlenev@mysql.com authored
which was caused by the same bulk insert optimization as bug #17764 but had slightly different symptoms.
-
kroki@mysql.com authored
While executing a trigger, we have to set thd->abort_on_warning to the value it had at trigger creation time.
-
- 18 Apr, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
-
- 12 Apr, 2006 1 commit
-
-
kroki@mysql.com authored
CONNECTION_ID() was implemented as a constant Item, i.e. an instance of Item_static_int_func class holding value computed at creation time. Since Items are created on parsing, and trigger statements are parsed on table open, the first connection to open a particular table would effectively set its own CONNECTION_ID() inside trigger statements for that table. Re-implement CONNECTION_ID() as a class derived from Item_int_func, and compute connection_id on every call to fix_fields().
-
- 29 Mar, 2006 1 commit
-
-
dlenev@mysql.com authored
A table with an on insert trigger was reported as crashed when the insert was processed with bulk insert mode on (handler::start_bulk_insert). The trigger was also selecting from the same table, and that caused the "crash". The same problem was present when an insert statement, which was processed in bulk mode, also used a stored function that was reading the same table. This fix disables bulk inserts if a statement uses functions or invokes triggers. Implementing more granular checks will require much more code and therefore can hardly be done in 5.0
-
- 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). .
-
- 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).
-
- 27 Feb, 2006 1 commit
-
-
dlenev@mysql.com authored
bug #13525 "Rename table does not keep info of triggers". Now we use MYSQLTEST_VARDIR in order to be able to run this test in different vardir. Also improved cleanup after the test.
-
- 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).
-
- 28 Jan, 2006 1 commit
-
-
dlenev@mysql.com authored
We should disallow usage of RETURN statement in triggers and emit error at parsing time (instead of crashing when trigger is fired).
-
- 24 Jan, 2006 1 commit
-
-
msvensson@neptunus.(none) 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
-
- 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.
-
- 22 Nov, 2005 2 commits
-
-
bell@sanja.is.com.ua authored
-
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.
-
- 17 Nov, 2005 1 commit
-
-
dlenev@mysql.com authored
which is now dropped" and bug #12329 "Bogus error msg when executing PS with stored procedure after SP was re-created".
-
- 14 Sep, 2005 1 commit
-
-
dlenev@mysql.com authored
This bug occurs when some trigger for table used by DML statement is created or changed while statement was waiting in lock_tables(). In this situation prelocking set which we have calculated becames invalid which can easily lead to errors and even in some cases to crashes. With proposed patch we no longer silently reopen tables in lock_tables(), instead caller of lock_tables() becomes responsible for reopening tables and recalculation of prelocking set.
-
- 02 Sep, 2005 1 commit
-
-
konstantin@mysql.com authored
The idea of the patch is to separate statement processing logic, such as parsing, validation of the parsed tree, execution and cleanup, from global query processing logic, such as logging, resetting priorities of a thread, resetting stored procedure cache, resetting thread count of errors and warnings. This makes PREPARE and EXECUTE behave similarly to the rest of SQL statements and allows their use in stored procedures. This patch contains a change in behaviour: until recently for each SQL prepared statement command, 2 queries were written to the general log, e.g. [Query] prepare stmt from @stmt_text; [Prepare] select * from t1 <-- contents of @stmt_text The chagne was necessary to prevent [Prepare] commands from being written to the general log when executing a stored procedure with Dynamic SQL. We should consider whether the old behavior is preferrable and probably restore it. This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs in Dynamic SQL reported before it was disabled).
-
- 18 Aug, 2005 1 commit
-
-
dlenev@mysql.com authored
If we are in stored function or trigger we should ensure that we won't change table that is already used by calling statement (this can damage table or easily cause infinite loops). Particularly this means that recursive triggers should be disallowed.
-
- 15 Aug, 2005 2 commits
-
-
monty@mysql.com authored
-
monty@mysql.com authored
This allows us to use statement replication with functions and triggers The following things are fixed with this patch: - NOW() and automatic timestamps takes the value from the main event for functions and triggers (which allows these to replicate with statement level logging) - No side effects for triggers or functions with auto-increment values(), last_insert_id(), rand() or found_rows() - Triggers can't return result sets Fixes bugs: #12480: NOW() is not constant in a trigger #12481: Using NOW() in a stored function breaks statement based replication #12482: Triggers has side effects with auto_increment values #11587: trigger causes lost connection error
-
- 10 Aug, 2005 1 commit
-
-
dlenev@mysql.com authored
We should not allow FLUSH statement to be executed inside both triggers and stored functions.
-
- 09 Aug, 2005 1 commit
-
-
dlenev@mysql.com authored
cause crash on update". Let us update "thd" pointer in LEX, all its units and in LEX::result before executing statement in trigger body, since triggers are associated with TABLE object and because of this can be used in different threads.
-
- 30 Jul, 2005 1 commit
-
-
bell@sanja.is.com.ua authored
-
- 28 Jul, 2005 1 commit
-
-
bell@sanja.is.com.ua authored
other sql_mode fixes
-
- 19 Jul, 2005 2 commits
-
-
dlenev@mysql.com authored
-
dlenev@mysql.com authored
"Triggers have the wrong namespace" "Triggers: duplicate names allowed" "Triggers: CREATE TRIGGER does not accept fully qualified names" "SHOW TRIGGERS"
-
- 13 Jul, 2005 2 commits
-
-
dlenev@mysql.com authored
all tables suggested by prelocking algorithm. Added test for bug #11889 "Server crashes when dropping trigger using stored routine" (which was fixed by previous patch).
-
dlenev@mysql.com authored
indirectly using non-cached function".
-
- 09 Jul, 2005 1 commit
-
-
dlenev@mysql.com authored
a table" with main tree.
-