Re: SPI_execp() failed in RI_FKey_cascade_del()

Hello,

| do pretty much. It uses the table owner as the deleter
| of the rows so revoking write from answer_summary won't

I didn't read carefully enough your previous post, sorry.
The table owner's privileges is used when deleting referenced
rows. I understood.

| It looks like admin has arwd on request...

Everything is getting more clear now... (step by step)

| 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)

sorry for bothering you again,

--
Gyozo Papp - pgerzson(at)freestart(dot)hu