From: | "Tommy McDaniel" <tommstein(at)myway(dot)com> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #5505: Busted referential integrity with triggers |
Date: | 2010-06-15 01:12:41 |
Message-ID: | 20100614211241.21351@web011.roc2.bluetie.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 whole point of foreign keys is to make the database ensure referential integrity is maintained instead of having to do it manually.
Tommy McDaniel
-----Original Message-----
From: "Tom Lane" [tgl(at)sss(dot)pgh(dot)pa(dot)us]
Date: 06/14/2010 08:13 AM
To: "Tommy McDaniel" <tommstein(at)myway(dot)com>
CC: pgsql-bugs(at)postgresql(dot)org
Subject: Re: [BUGS] BUG #5505: Busted referential integrity with triggers
"Tommy McDaniel" <tommstein(at)myway(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-06-15 03:41:03 | Re: BUG #5505: Busted referential integrity with triggers |
Previous Message | Kevin Grittner | 2010-06-14 15:10:14 | Re: BUG #5507: missing chunk number 0 for toast value XXXXX in pg_toast_XXXXX |