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. #
#================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
