Re: SPI_execp() failed in RI_FKey_cascade_del()

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: "Papp, Gyozo" <pgerzson(at)freestart(dot)hu>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: SPI_execp() failed in RI_FKey_cascade_del()
Date: 2002-04-10 15:41:24
Message-ID: 20020410083719.A13066-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Gregory Wood 2002-04-10 15:58:04 Re: Postgresql 7.2
Previous Message Johann Zuschlag 2002-04-10 15:35:03 Keyword position was: Why does this not work? (keyword 'TEXT')