Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.2-3, 10.2.2-2, 10.2.2-4
Description
Many triggers for the same event per table (e.g. many BEFORE DELETE triggerts).
This can be ported from 5.7
Looked at the MySQL 5.7 implementation. Too complex and too many not needed changed and moving of things to different files that make it very hard to follow code changes over time.
Will do this with new code, but will take test cases from MySQL 5.7
New functionality:
- "Any" amount of same events
- New syntax with
{ FOLLOWS | PRECEDES } trigger_name
CREATE [OR REPLACE]
[DEFINER = { user | CURRENT_USER }]
TRIGGER [IF NOT EXISTS] trigger_name trigger_time trigger_event
ON tbl_name FOR EACH ROW
[{ FOLLOWS | PRECEDES }other_trigger_name ]
trigger_stmt
Attachments
Issue Links
- is part of
-
MDEV-10137 Providing compatibility to other databases
-
- Open
-
- relates to
-
MDEV-10915 Multiple triggers are not counted in Executed_triggers status variable
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
Activity
As it's completely optional to add a trigger for table, I don't see any reason to disable this.
We already have way too many startup options for MariaDB.
If one doesn't think a person is capable of using TRIGGER's, then one shouldn't give him the TRIGGER privilege.
Almost every feature can be limited in some way, the strangest example is sql_safe_updates.
But I realized that my proposal would add an incompatibility with MySQL, so it isn't a good idea.
Another reason for not adding an option for this is that multiple triggers per table is standard ANSI SQL feature.
Optionally disabling all features in SQL that may be problematic for some users is task independent of this one. For example, I think a lot of people would find it useful if DROP TABLE was disabled after they have dropped an important table 
Can this be disabled? Multiple triggers of the same type can be useful, but can also be chaotic and hard to debug...