Semantics
-
BEFOREtriggers are fired before changes to the system tables.AFTERtriggers are fired after system table changes.ImportantImportant RuleThe event type
[BEFORE | AFTER]of a DDL trigger cannot be changed. -
When a DDL statement fires a trigger that raises an exception (
BEFOREorAFTER, intentionally or unintentionally) the statement will not be committed.That is, exceptions can be used to ensure that a DDL operation will fail if the conditions are not precisely as intended. -
DDL trigger actions are executed only when committing the transaction in which the affected DDL command runs.Never overlook the fact that what is possible to do in an
AFTERtrigger is exactly what is possible to do after a DDL command without autocommit.You cannot, for example, create a table and then use it in the trigger. -
With “
CREATE OR ALTER” statements, a trigger is fired one time at theCREATEevent or theALTERevent, according to the previous existence of the object.WithRECREATEstatements, a trigger is fired for theDROPevent if the object exists, and for theCREATEevent. -
ALTERandDROPevents are generally not fired when the object name does not exist.For the exception, see point 6. -
The exception to rule 5 is that
BEFORE ALTER/DROP USERtriggers fire even when the username does not exist.This is because, underneath, these commands perform DML on the security database, and the verification is not done before the command on it is run.This is likely to be different with embedded users, so do not write code that depends on this. -
If an exception is raised after the DDL command starts its execution and before
AFTERtriggers are fired,AFTERtriggers will not be fired. -
Packaged procedures and functions do not fire individual
{CREATE | ALTER | DROP} {PROCEDURE | FUNCTION}triggers.