"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
