An error occurred fetching the project authors.
- 19 Apr, 2006 1 commit
-
-
dlenev@mysql.com authored
which was caused by the same bulk insert optimization as bug #17764 but had slightly different symptoms.
-
- 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 2 commits
-
-
dlenev@mysql.com authored
a table" with main tree.
-
dlenev@mysql.com authored
crash if referencing a table" and several other related bugs. Fix for bug #11834 "Re-execution of prepared statement with dropped function crashes server." which was spotted during work on previous bugs. Also couple of nice cleanups: - Replaced two separate hashes for stored routines used by statement with one. - Now instead of doing one pass through all routines used in statement for caching them and then doing another pass for adding their tables to table list, we do only one pass during which do both things.
-
- 29 Jun, 2005 1 commit
-
-
dlenev@brandersnatch.localdomain authored
(The bug itself was fixed earlier by the patch that fixed bug #5860 "Multi-table UPDATE does not activate update triggers" and several other bugs).
-
- 30 May, 2005 1 commit
-
-
dlenev@brandersnatch.localdomain authored
databases" and basic handling of errors which happen in triggers. (The bug itself was fixed by several previous patches). Fixed bug in multi-delete which were exposed by these tests.
-
- 24 May, 2005 1 commit
-
-
dlenev@brandersnatch.localdomain authored
#5860 "Multi-table UPDATE does not activate update triggers" #6812 "Triggers are not activated for INSERT ... SELECT" #8755 "Trigger is not activated by LOAD DATA". This patch also implements proper handling of triggers for special forms of insert like REPLACE or INSERT ... ON DUPLICATE KEY UPDATE. Also now we don't call after trigger in case when we have failed to inserted/update or delete row. Trigger failure should stop statement execution. I have not properly tested handling of errors which happen inside of triggers in this patch, since it is simplier to do this once we will be able to access tables from triggers.
-
- 27 Mar, 2005 1 commit
-
-
dlenev@brandersnatch.localdomain authored
#6559 "DROP DATABASE forgets to drop triggers". If we drop table we should also drop all triggers associated with it. To do this we have to check for existence of .TRG file when we are dropping table and delete it too.
-
- 04 Jan, 2005 1 commit
-
-
monty@mysql.com authored
Add support for warnings for prepare of prepared statements Fixed test to work with --ps-protocol Fixed some test results
-
- 03 Jan, 2005 1 commit
-
-
monty@mysql.com authored
(Old code failed for INSERT ... ON DUPLICATE with prepared statements) Instead, always reset table->insert_values on open.
-
- 24 Nov, 2004 1 commit
-
-
dlenev@brandersnatch.localdomain authored
out of order". (final version) Now instead of binding Item_trigger_field to TABLE objects during trigger definition parsing at table open, we perform pass through special list of all such objects in trigger. This allows easily check all references to fields in old/new version of row in trigger during execution of CREATE TRIGGER statement (this is more courtesy for users since we can't check everything anyway). We also report that such reference is bad by returning error from Item_trigger_field::fix_fields() method (instead of setup_field()) This means that if trigger is broken we will bark during trigger execution instead of trigger definition parsing at table open. (i.e. now we allow to open tables with broken triggers).
-
- 12 Nov, 2004 1 commit
-
-
dlenev@brandersnatch.localdomain authored
If we have DELETE with always true WHERE clause we should not use optimized delete_all_rows() method for tables with DELETE triggers, because in this case we will lose side-effect of deletion.
-
- 08 Oct, 2004 1 commit
-
-
dlenev@brandersnatch.localdomain authored
Fixed small error in new .FRM parser which caused it to handle improperly escaped strings.
-
- 09 Sep, 2004 1 commit
-
-
dlenev@brandersnatch.localdomain authored
-