To define a trigger, you need the Oracle Rdb READ and DEFINE
    privileges to the subject relation. If any triggered statement
    specifies some form of update operation, then CONTROL and the
    appropriate update privilege (ERASE, MODIFY, or WRITE) to the
    relations specified by the triggered action statements are also
    required.

    Each trigger is associated with a single subject relation, will
    be evaluated at a specific time for a particular type of update
    on that relation, and specifies a series of 'triggered' actions.
    Each triggered action consists of an optional condition and one
    or more statements to be evaluated either once only or for each
    record of the relation being updated.

    By defining combinations of relation-specific constraints and
    triggers, you can help to preserve integrity for a database.
    However, the relation-specific constraints and triggers that you
    define only preserve data integrity for the fields and relations
    specified in the constraints and triggers, not for the entire
    database.

    You can define a trigger only after you have invoked the
    database. See the DEFINE_RELATION statement.

    You must execute this statement in a read/write transaction.
    If there is no active transaction and you issue this statement,
    Oracle Rdb starts a read/write transaction implicitly.

    Other users are allowed to be attached to the database when you
    issue the DEFINE TRIGGER statement.

    Triggers that update rows of the trigger subject relation or add
    rows to the trigger subject relation can cause infinite loops
    or inconsistent results to be returned, as in the following two
    conditions:

    o  A BEFORE MODIFY trigger on relation X that inserts a row into
       relation X

    o  A MODIFY statement affecting all the rows in relation X

    Considering these two conditions, the MODIFY statement will loop
    until all resources are consumed because for each row updated,
    a new row will be added, which in turn will be updated, and so
    forth.

    When subject relation rows are being retrieved using an index,
    there is the possibility that a triggered action operating on
    the same relation could affect the index (by changing index key
    values or adding new keys) such that the triggering statement
    behaves in a different manner than when there is no trigger
    involved.

    Currently, only avoidance methods can be suggested for this
    problem. The best way to avoid this problem is to construct
    any such triggers to operate only on rows that are either the
    current subject relation row, or that will never be selected by
    the triggering statement. A more difficult avoidance method is
    to restructure triggering statements such that they could never
    select a row that could have been updated or added by a trigger
    action. Some circumstances will require a combination of these
    methods.