Re: SPI_execp() failed in RI_FKey_cascade_del()
От | Stephan Szabo |
---|---|
Тема | Re: SPI_execp() failed in RI_FKey_cascade_del() |
Дата | |
Msg-id | 20020410083719.A13066-100000@megazone23.bigpanda.com обсуждение исходный текст |
Ответ на | Re: SPI_execp() failed in RI_FKey_cascade_del() ("Papp, Gyozo" <pgerzson@freestart.hu>) |
Список | pgsql-general |
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.
В списке pgsql-general по дате отправления: