Re: Problems with RULE

"Jens Hartwig" <jens.hartwig@t-systems.de> writes:
> I tried to implement the following rule: if someone wants to delete a record
> from a table t_xyz (id integer, deleted boolean) the record should get a
> delete-flag (deleted = true). When this "pre-deleted" record is deleted for
> the next time it should be physically deleted from the database.

> I implemented the following rule:

>   CREATE RULE r_del_xyz
>   AS ON DELETE TO t_xyz WHERE (old.deleted = false)
>   DO INSTEAD
>     UPDATE t_xyz
>     SET deleted = true
>     WHERE id = old.id;

> Now I tested the new rule:

>   INSERT INTO t_xyz VALUES (1, false);
>   INSERT INTO t_xyz VALUES (2, false);
>   DELETE FROM t_xyz WHERE id = 1;
>   SELECT * FROM t_xyz ;

>    id | deleted
>   ----+---------
>     2 | f

> What has happened? The rule seems to be ignored and the record was deleted!

You'd probably have better luck doing this with a trigger.  With this
rule, the DELETE query expands into two operations, which can be written
as:

UPDATE t_xyz SET deleted = true
WHERE id IN (SELECT old.id FROM t_xyz old WHERE old.id = 1 AND old.deleted = false);

DELETE FROM t_xyz WHERE id = 1 AND NOT (deleted = false);

The problem is that the second query can see the results of the first.
Unfortunately, while that's bad for this example, it's necessary for
other more-useful examples.  So I do not think this is a bug.

In my experience, anything you want to do that can be expressed as
an operation or condition on an individual target tuple of an
INSERT/UPDATE/DELETE is best done in a trigger, for reasons of both
performance and understandability.  Rules are good for things that
involve conditions on multiple tuples.
        regards, tom lane