Re: BUG #5505: Busted referential integrity with triggers - Mailing list pgsql-bugs

From Tommy McDaniel
Subject Re: BUG #5505: Busted referential integrity with triggers
Date
Msg-id 20100614211241.21351@web011.roc2.bluetie.com
Whole thread Raw
In response to BUG #5505: Busted referential integrity with triggers  ("Tommy McDaniel" <tommstein@myway.com>)
Responses Re: BUG #5505: Busted referential integrity with triggers  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
I can understand firing the triggers. But what's up with not checking that =
the foreign key constraint is met? If the user has to manually ensure that =
values maintain referential integrity, why have foreign keys at all? The wh=
ole point of foreign keys is to make the database ensure referential integr=
ity is maintained instead of having to do it manually.

Tommy McDaniel




-----Original Message-----
From: "Tom Lane" [tgl@sss.pgh.pa.us]
Date: 06/14/2010 08:13 AM
To: "Tommy McDaniel" <tommstein@myway.com>
CC: pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #5505: Busted referential integrity with triggers=
=20

"Tommy McDaniel" <tommstein@myway.com> writes:
> Let us also create a trigger to disable UPDATEs on table_2:
> ...
> And, we have now broken referential integrity.

Yup, this is not a bug, it's a feature.  Triggers fire on
referential-integrity updates.  (If they didn't, you could not for
example have a logging trigger log RI actions.)  If you don't want
to break RI, you'd better think more carefully about what your
trigger does.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Greg Stark
Date:
Subject: Re: BUG #5507: missing chunk number 0 for toast value XXXXX in pg_toast_XXXXX
Next
From: Tom Lane
Date:
Subject: Re: BUG #5505: Busted referential integrity with triggers