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).
- 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.
impossible view security".
We should not expose names of tables which are explicitly or implicitly (via
routine or trigger) used by view even if we find that they are missing.
So during building of list of prelocked tables for statement we track which
routines (and therefore tables for these routines) are used from views. We
mark elements of LEX::routines set which correspond to routines used in views
by setting Sroutine_hash_entry::belong_to_view member to point to TABLE_LIST
object for topmost view which uses routine. We propagate this mark to all
routines which are used by this routine and which we add to this set. We also
mark tables used by such routine which we add to the list of tables for
prelocking as belonging to this view.
Added error checking for errors when attempting to use stored procedures
after the mysql.proc table has been dropped, corrupted, or tampered with.
Test cases were put in a separate file (sp-destruct.test).
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.
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
its body, but lets each statement to get/release its own locks. This allows a broader set
of statements to be executed inside PROCEDUREs (but breaks replication)
This patch should fix BUG#8072, BUG#8766, BUG#9563, BUG#11126
"Triggers have the wrong namespace"
"Triggers: duplicate names allowed"
"Triggers: CREATE TRIGGER does not accept fully qualified names"
"SHOW TRIGGERS"
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.
We should not allow explicit or implicit transaction commits inside
of stored functions or triggers (so in autocommit mode we should not
do commits after execution of sub-statement).
Also since we don't support nested statement transactions in 5.0,
we shouldn't commit or rollback stmt transactions while we are inside
stored functions or triggers. This should be fixed in later (>=5.1)
releases.
#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.
and some SP-related cleanups.
- We don't have separate stage for calculation of list of tables
to be prelocked and doing implicit LOCK/UNLOCK any more.
Instead we calculate this list at open_tables() and do implicit
LOCK in lock_tables() (and UNLOCK in close_thread_tables()).
Also now we support cases when same table (with same alias) is
used several times in the same query in SP.
- Cleaned up execution of SP. Moved all common code which handles
LEX and does preparations before statement execution or complex
expression evaluation to auxilary sp_lex_keeper class. Now
all statements in SP (and corresponding instructions) that
evaluate expression which can contain subquery have their
own LEX.
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).
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.
Mostly needed for Monty for him getting notion what needed for triggers
from new .FRM format.
Things to be done:
- Right placement of trigger's invocations
- Right handling of errors in triggers (including transaction rollback)
- Support for priviliges
- Right handling of DROP/RENAME table (hope that it will be handled automatically
with merging of .TRG into .FRM file)
- Saving/restoring some information critical for trigger creation and replication
with their definitions (e.g. sql_mode, creator, ...)
- Replication
Already has some known bugs so probably not for general review.
