</itemizedlist>
</para>

<para>
    The programmer can ensure that any desired <literal>INSTEAD</literal> rule is the one
    that sets the command status in the second case, by giving it the
    alphabetically last rule name among the active rules, so that it
    gets applied last.
</para>
</sect1>

<sect1 id="rules-triggers">
<title>Rules Versus Triggers</title>

<indexterm zone="rules-triggers">
 <primary>rule</primary>
 <secondary sortas="Trigger">compared with triggers</secondary>
</indexterm>

<indexterm zone="rules-triggers">
 <primary>trigger</primary>
 <secondary sortas="Regeln">compared with rules</secondary>
</indexterm>

<para>
    Many things that can be done using triggers can also be
    implemented using the <productname>PostgreSQL</productname>
    rule system.  One of the things that cannot be implemented by
    rules are some kinds of constraints, especially foreign keys. It is possible
    to place a qualified rule that rewrites a command to <literal>NOTHING</literal>
    if the value of a column does not appear in another table.
    But then the data is silently thrown away and that's
    not a good idea. If checks for valid values are required,
    and in the case of an invalid value an error message should
    be generated, it must be done by a trigger.
</para>

<para>
    In this chapter, we focused on using rules to update views. All of
    the update rule examples in this chapter can also be implemented
    using <literal>INSTEAD OF</literal> triggers on the views.  Writing such
    triggers is often easier than writing rules, particularly if complex
    logic is required to perform the update.
</para>

<para>
    For the things that can be implemented by both, which is best
    depends on the usage of the database.
    A trigger is fired once for each affected row. A rule modifies
    the query or generates an additional query. So if many
    rows are affected in one statement, a rule issuing one extra
    command is likely to be faster than a trigger that is
    called for every single row and must re-determine what to do
    many times.  However, the trigger approach is conceptually far
    simpler than the rule approach, and is easier for novices to get right.
</para>

<para>
    Here we show an example of how the choice of rules versus triggers
    plays out in one situation.  There are two tables:

<programlisting>
CREATE TABLE computer (
    hostname        text,    -- indexed
    manufacturer    text     -- indexed
);

CREATE TABLE software (
    software        text,    -- indexed
    hostname        text     -- indexed
);
</programlisting>

    Both tables have many thousands of rows and the indexes on
    <structfield>hostname</structfield> are unique.  The rule or trigger should
    implement a constraint that deletes rows from <literal>software</literal>
    that reference a deleted computer.  The trigger would use this command:

<programlisting>
DELETE FROM software WHERE hostname = $1;
</programlisting>

    Since the trigger is called for each individual row deleted from
    <literal>computer</literal>, it can prepare and save the plan for this
    command and pass the <structfield>hostname</structfield> value in the
    parameter.  The rule would be written as:

<programlisting>
CREATE RULE computer_del AS ON DELETE TO computer
    DO DELETE FROM software WHERE hostname = OLD.hostname;
</programlisting>
   </para>

   <para>
    Now we look at different types of deletes. In the case of a:

<programlisting>
DELETE FROM computer WHERE hostname = 'mypc.local.net';
</programlisting>

    the table <literal>computer</literal> is scanned by index (fast), and the
    command issued by the trigger would also use an index scan (also fast).
    The extra command from the rule would be:

<programlisting>
DELETE FROM software