Skip site navigation (1) Skip section navigation (2)

Re: BUG #5505: Busted referential integrity with triggers

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Tommy McDaniel" <tommstein(at)myway(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5505: Busted referential integrity with triggers
Date: 2010-06-15 03:41:03
Message-ID: 26428.1276573263@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Tommy McDaniel" <tommstein(at)myway(dot)com> writes:
> 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.

[ shrug... ]  The database is doing its best.  Do you really want us to
incur the extra overhead of checking that a trigger didn't screw things
up?  Exactly how far should that go?  For instance, maybe we have to
check that the trigger didn't queue a subsequent event that will make
the undesired change after we look?  I can assure you that far more
people would complain about the useless overhead induced by rechecking
than will complain about the fact that they can write triggers that will
fire on RI updates.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: 中嶋 信二Date: 2010-06-15 07:01:51
Subject: Re: BUG #5507: missing chunk number 0 for toast value XXXXX in pg_toast_XXXXX
Previous:From: Tommy McDanielDate: 2010-06-15 01:12:41
Subject: Re: BUG #5505: Busted referential integrity with triggers

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group