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-10137Providing compatibility to other databases
Open
relates to
MDEV-10915Multiple triggers are not counted in Executed_triggers status variable
Closed
MDEV-10916In trigger's CREATED time microseconds are misinterpreted
Closed
MDEV-10924CREATE OR REPLACE TRIGGER which fails on PRECEDES/FOLLOWS drops the trigger, but isn't written to binlog; replication fails
Closed
MDEV-10926Extra dot (period) in the error text for ER_REFERENCED_TRG_DOES_NOT_EXIST
Closed
MDEV-10930FOLLOWS in lex.h is out of alphabetical order
Closed
MDEV-10911Make SHOW TRIGGERS to show triggers' action order
Closed
MDEV-11033"follows" does not show up in "show create trigger" output
Can this be disabled? Multiple triggers of the same type can be useful, but can also be chaotic and hard to debug...
Federico Razzoli
added a comment - Can this be disabled? Multiple triggers of the same type can be useful, but can also be chaotic and hard to debug...
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.
Michael Widenius
added a comment - 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.
Federico Razzoli
added a comment - 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
Michael Widenius
added a comment - 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
Task
Major
MDEV-10137 Providing compatibility to other databases
MDEV-10915 Multiple triggers are not counted in Executed_triggers status variable
Can this be disabled? Multiple triggers of the same type can be useful, but can also be chaotic and hard to debug...