Creating a trigger

In order to create a trigger, a function must first exist for it to execute. PostgreSQL supports many types of functions, including those defined by SQL, PL/pgSQL, and C. As of PostgreSQL 7.1.x, a trigger may use a function defined in any language, with the exception that the function cannot be defined as a purely SQL function.

Once a function is defined, a trigger may be defined to call that function either before or after an event on a specified table. Here is the syntax to create a trigger, followed by a description of its syntax:

  CREATE TRIGGER 
name
 { BEFORE | AFTER } { 
event
 [ OR 
event
 ... ] }
                 ON 
tablename

                 FOR EACH { ROW | STATEMENT }
                 EXECUTE PROCEDURE 
functionname
 ( 
arguments
 )

While PostgreSQL tables support constraints to perform simple checks against static criteria, sometimes more involved procedures may be needed to validate input values. This is a typical example of where a trigger might be useful.

A trigger may be used to validate input values by preparing a validation function to be executed before values are inserted into a table, or before values in a table are updated. The function can then be made responsible for verifying that the values meet a complex set of restrictions, and even return an appropriate error through PostgreSQL's error logging system.

Suppose that you have written a function in a procedural language that validates attempted INSERT or UPDATE values on the shipments table, and that then performs an update on the stock table to decrement the inventory for the shipment. This function could be written in any language that PostgreSQL supports (with the noted exception of pure SQL).

Specifically, suppose that this function verifies that both the provided customer_id and isbn exist in their respective customers and editions tables. If at least one is missing, a meaningful error is returned. Otherwise, the SQL statement is allowed to execute, and on a successful INSERT statement, the stock table is automatically decremented to reflect the drop in stock from the shipment.

Example 7-35 creates a trigger to be "fired" immediately before an INSERT or UPDATE statement is processed on the shipments table. The trigger invokes the check_shipment_addition() function once per each modified row.

booktown=# 
CREATE TRIGGER check_shipment

booktown-# 
               BEFORE INSERT OR UPDATE

booktown-# 
               ON shipments FOR EACH ROW

booktown-# 
               EXECUTE PROCEDURE check_shipment_addition();

CREATE

Since the check_shipment trigger is configured to execute the check_shipment_addition() function for both INSERT and UPDATE statements, the integrity of the customer_id and isbn columns are fairly robustly maintained. Its use of the ROW keyword ensures that each added or modified row will be processed by the check_shipment_addition() validation function.

No arguments are passed to the check_shipment_addition() function, as it uses internal PL/pgSQL variables to check incoming rows. See Example 11-53, in Chapter 11, for the implementation of the check_shipment_addition() function, written in PL/pgSQL.

Viewing a trigger

Triggers are stored in the pg_trigger PostgreSQL system table, and can have their characteristics queried after creation. The structure of the pg_trigger table is shown in Table 7-3.

Most of the columns in the Table 7-3 column are unlikely to be useful in a direct query. The most immediately relevant attributes of the pg_trigger system table are tgrelid and tgname.

The tgrelid value is the trigger's relation identifier number. This value is of type oid, and corresponds to the relfilenode column in the pg_class. The tgname is the identifier which represents the name of the trigger, as specified in the CREATE TRIGGER command when the trigger was created.

Removing a trigger

The DROP TRIGGER command removes a trigger permanently from the database. Similar to the CREATE TRIGGER command, using this command requires you to be either the owner of the trigger, or a superuser.

Here is the syntax to remove an existing trigger:

  DROP TRIGGER 
name
 ON 
table

Example 7-36 drops the check_shipment trigger placed on the shipments table.

booktown=# 
DROP TRIGGER check_shipment ON shipments;

DROP

The DROP statement indicates that the trigger was successfully dropped. Notice that you must specify not only the name of the trigger that you wish to remove, but also the table on which it is placed.

If you are unsure which table a particular trigger is placed on, you can derive this information from PostgreSQL's system tables. For example, you can perform a join between the pg_trigger system table's tgrelid column and the pg_class system table's relfilenode column, comparing the name of the trigger against the tgname column. Example 7-37 demonstrates such a query to check the assigned relation (relname) associated with the trigger named check_shipment.

booktown=# 
SELECT relname FROM pg_class

booktown-# 
               INNER JOIN pg_trigger

booktown-# 
               ON (tgrelid = relfilenode)

booktown-# 
               WHERE tgname = 'check_shipment';

  relname
-----------
 shipments
(1 row)