On 12/8/2005 9:12 PM, Luca Pireddu wrote:
> I wrote a trigger function with the intent of preventing the deletion of a
> parent record when a referencing record would not allow it. However, the
> result is that the referencing record stays, but the referenced one is gone,
> so that my foreign key constraint is not respected. The behaviour can be
> replicated with the following:
You did something else than intended. You prevented deletion of the
referencing (dependent) record. That is where you defined the trigger,
and that is what renders the foreign key constraints DELETE operation
from dependent into a NOP.
I guess that counts more as a pilot error.
Jan
>
> create table parent(id serial primary key);
> create table dependent (id integer primary key references parent on delete
> cascade);
>
> create or replace function check_delete() returns trigger as $$
> BEGIN
> if TG_OP = 'DELETE' then
> raise notice 'preventing delete';
> return null;
> else
> return OLD;
> end if;
> END;
> $$
> language 'plpgsql';
>
> CREATE TRIGGER trig_check_delete BEFORE DELETE ON dependent
> FOR EACH ROW EXECUTE PROCEDURE check_delete();
>
> insert into parent values(1);
> insert into dependent values(1);
> delete from parent;
>
> The record in the dependent table is left behind, while the referenced parent
> is gone. Is this a bug?
>
> I'm using PostgreSQL version 8.0.4 on Linux.
>
> Luca
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
