Re: Affected # of Rows After TRIGGER/RULE Return

Поиск
Список
Период
Сортировка
От Volkan YAZICI
Тема Re: Affected # of Rows After TRIGGER/RULE Return
Дата
Msg-id 87mymtico5.fsf@alamut.mobiliz.com.tr
обсуждение исходный текст
Ответ на Re: Affected # of Rows After TRIGGER/RULE Return  (Gerald Quimpo <bopolissimus.lists@gmail.com>)
Ответы Re: Affected # of Rows After TRIGGER/RULE Return
Список pgsql-general
On Wed, 14 May 2008, Gerald Quimpo <bopolissimus.lists@gmail.com> writes:
> Instead of trying to update the row in place, insert the row again,
> but with the field you need to mangle (in your example, "plate",
> in my example below, "k") already mangled.  this only works if
> the field you're mangling is the primary key.  if some other field
> is the primary key, you will need to mangle that too, if possible.
> since you'll have already inserted the row, just return OLD and let
> the old row actually be deleted.

I've considered that too. But the problem is that there are nearly 50-60
tables referencing to the related row about the be deleted. Therefore,
if I'd return OLD from the trigger, all other rows referencing to OLD
will get deleted because of ON DELETE CASCADE. But, if there would be
some way to tell the ON DELETE CASCADE constraints that "Hey, don't move
yet. I'll INSERT a new row with what you thought to be missing
previously." there won't be a problem.

I hope I understand you correctly. Did I miss anything? Any ideas?


Regards.

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

Предыдущее
От: Gerald Quimpo
Дата:
Сообщение: Re: Affected # of Rows After TRIGGER/RULE Return
Следующее
От: "Albe Laurenz"
Дата:
Сообщение: Re: C function