Documentation: Clarify the difference for triggers between Khepri and RDBMS

doc/overview.edoc

@@ -500,5 +500,23 @@ executed at least once. Therefore, if the Ra leader changes before the
 execution of the stored procedure could be confirmed to the Khepri state
 machine, the execution will be retried on the new Ra leader.
 
-This means that the stored procedure could be executed multiple times. There
-it is important it is idempotent.
+This means that the stored procedure could be executed multiple times.
+Therefore it is important it is idempotent.
+
+=== Differences with triggers in RDBMS ===
+
+As described earlier, the rationale for triggers in Khepri is that sometimes,
+one needs to execute some code with side effects (e.g. sending a message to a
+process) after a record was modified in the database. This can't happen in a
+transaction because side effects are forbiden. The caller could handle that
+after he modifies the record, but the record could be indirectly modified
+(deleted) as a consequence of another record being modified or deleted. In
+this case, the caller can't do anything.
+
+Because of the freedom they need, <strong>triggers are not allowed to mess
+with the database directly</strong>. In other words, they must go through the
+regular Khepri API like any caller. Triggers do not have any privileges or
+blanket approvals to tamper with the data.
+
+So even though Khepri uses the same naming than many RDBMS, triggers in Khepri
+can't have unexpected consequences.