Tom,
You can't have your cake and eat it too, Josh. If we make the RI
mechanism operate at a level underneath triggers, then we'll lose all
sorts of useful capability that people are depending on. A couple of
examples:
* the ability to log table changes caused by RI cascades
* the ability to
Tom Lane writes:
> It doesn't say that, because it isn't true. What is true is that if you
> make a trigger that prevents updates from happening, it breaks RI
> updates as well as directly-user-initiated updates.
Can we detect that this happened and throw an error? I suspect not, though,
sinc
Tom Lane wrote:
Josh Berkus writes:
Summary: self-referential FKs are not enforced properly in the
presence of BEFORE triggers
This isn't a bug. If you create triggers that prevent the RI actions
from being taken, it's your own problem.
Huh? Since when was it OK by us to have data
Josh Berkus writes:
> Tom Lane wrote:
>> This isn't a bug. If you create triggers that prevent the RI actions
>> from being taken, it's your own problem.
> Huh? Since when was it OK by us to have data which violates a declared
> FK under *any* circumstances?
You can't have your cake and eat i
Josh Berkus writes:
> Summary: self-referential FKs are not enforced properly in the
> presence of BEFORE triggers
This isn't a bug. If you create triggers that prevent the RI actions
from being taken, it's your own problem.
regards, tom lane
--
Sent via pgsql-bu
Version: 8.3.5
Install: self-compile on 64-bit Ubuntu Linux
also reproduced by AndrewSN on another platform
Summary: self-referential FKs are not enforced properly in the
presence of BEFORE triggers
Test Case:
-- create two tables, one of which is the master table (reftable) the
