On Thu, 11 Apr 2002, Papp, Gyozo wrote:
> | I'm not sure I understand, but for cases wher you want
> | one of the actions or you want the action to fail if a row is referenced
> | the foreign key is the right thing usually. If you only want an
> | insert check, foreign keys won't do that because they must always be
> | satisified which means something has to give when you modify keys or
> | delete a referenced row.
>
> What I really want is the following:
>
> - Noone in any circumstances can insert a row into "answer" which
> refers to a non-existent "request". I think I did good choice with
> using foreign keys to check if a "request" exists.
>
> But...
>
> - after a record is inserted into "answer", it must be locked. The
> table "answer" acts as an archive, no modification is allowed
> excepted one case. To be more specific:
> - noone in any circumstances can update any row in "answer",
> - deleting from "answer" is allowed only when it's triggered by
> deleting from the referenced "request". It seems to be good
> solution that foreign key has the "ON DELETE CASCADE" clause.
> (only admin allowed to perform such an action)
Okay, yes, that should work with on delete cascade and setting up the
permissions appropriately excepting that the table owner can delete
from the table directly.
