Triggers, Rules, and Views - PostgreSQL Developer's Guide - page 94

We noticed that the INSERT operation was skipped and the row was not inserted.
Now, try inserting a row again into tab_python , but this time with a smaller emp_id
using the following statement:
warehouse_db=# INSERT INTO tab_python VALUES (3, 'Roger',
'Boston');
Now, check whether this time the row is inserted:
warehouse_db=# SELECT * FROM tab_python;
emp_id | emp_name | emp_city
--------+----------+----------
1 | Adam | Chicago
2 | John | Miami
3 | Roger | Boston
(3 rows)
PostgreSQL rules
Things implemented through triggers can be achieved through rules as well. In fact,
you can do more than this. To be concise, the PostgreSQL rule system is actually an
implementation of query rewriting. The query rewrite module is located between the
parser and the planner .
Views in PostgreSQL are implemented using rules.
We will not go through an in-depth and tedious explanation of rules but it will be
easy to skim through its basic concept.
Well, this is how the whole story begins and ends. A query is received by the server
program and parsed by the parser that generates the query tree (it is an internal
representation of an SQL statement). Before this query tree can be passed to the
planner, the rules module rewrites the query tree with user-deined rewritten rules
stored as a query tree in the catalog table pg_rewrite , the resultant output is another
query tree for the planner that decides the optimal execution plan for the query.
Rules should not reference a table that already has
another associated rule set.