Re: SPI_execp() failed in RI_FKey_cascade_del()

Поиск
Список
Период
Сортировка
От Papp, Gyozo
Тема Re: SPI_execp() failed in RI_FKey_cascade_del()
Дата
Msg-id 003801c1e17f$bc2c4a80$01fdfea9@jaguar
обсуждение исходный текст
Ответ на Re: SPI_execp() failed in RI_FKey_cascade_del()  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Ответы Re: SPI_execp() failed in RI_FKey_cascade_del()  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
Список pgsql-general
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@freestart.hu




В списке pgsql-general по дате отправления:

Предыдущее
От: Gunther Schadow
Дата:
Сообщение: Re: Critical performance problems on large databases
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: Critical performance problems on large databases