On Tue, 9 Apr 2002, Papp, Gyozo wrote:
> | I think I see something that might be doing it...
> | There's a rule on answer_summary that forces deletes to be
> | negated which means the trigger sees that the delete wasn't
> | executed which would give the error since the constraint
> | would no longer be satisfied.
>
> So, if I drop these rules and I try to protect my database
> with a right acl system (grant + revoke), it should work.
Well, it's not going to not delete those rows whatever you
do pretty much. It uses the table owner as the deleter
of the rows so revoking write from answer_summary won't
probably work (if it does, that's a bug).
In any case, if it can't delete them, it's a constraint
violation and it should error at some point (probably
currently with the SPI_execp).
I'm guessing the intent was that on insert to answer_summary
the row needed to be there but from that point forward
you don't care if the row gets deleted in the referenced
table? If so, you're probably best off writing a small
plpgsql trigger function to do the check, foreign keys
have a bunch of semantics you don't want.