burn_ALL,

Черезжопной функцией. Иключительно для любителей острых приключений.

Прочитайте про опции ON DELETE, ON UPDATE объявления ссылочной целостности .

burn_ALL,

Специально для Вас (точнее для тех, кто умеет принимать советы) почитаю в слух документацию:
http://www.postgresql.org/docs/9.2/static/sql-createtable.html In addition, when the data in the referenced columns is changed, certain actions are performed on the data in this table's columns. The ON DELETE clause specifies the action to perform when a referenced row in the referenced table is being deleted. Likewise, the ON UPDATE clause specifies the action to perform when a referenced column in the referenced table is being updated to a new value. If the row is updated, but the referenced column is not actually changed, no action is done. Referential actions other than the NO ACTION check cannot be deferred, even if the constraint is declared deferrable. There are the following possible actions for each clause:

NO ACTION

Produce an error indicating that the deletion or update would create a foreign key constraint violation. If the constraint is deferred, this error will be produced at constraint check time if there still exist any referencing rows. This is the default action.
RESTRICT

Produce an error indicating that the deletion or update would create a foreign key constraint violation. This is the same as NO ACTION except that the check is not deferrable.
CASCADE

Delete any rows referencing the deleted row, or update the value of the referencing column to the new value of the referenced column, respectively.


Таки образом, выставление опции RESTRICT (она подразумевается по умолчанию) вызывает ошибку нарушения ссылочной целостности при попытке изменить ключевое поле.
Кстати, почему вообще возник вопрос. Чем не устраивает поведение по умолчанию при наличии ссылочной целостности?

Поэтому черезжопным способом пользуюсь не я.
Продолжайте впихивать странные конструкции в интересные места.

Во-вторых: что-то не устраивает - пожалуйтесь модератору.
Во-первых: Про Вас уже давно забыли. Взрослые люди обсуждают действительно интересные вопросы.


Раз уж Вы (а точнее вдумчивый читатель) тут, то объясните что будет происходить каждый раз при срабатывании триггера. Особенно интересует часть, вырванная из контекста:
burn_ALLselect * FROM version where id = ANY(NEW.dependencies)


Особо осветите вопрсы:
- Что произойдет со скоростью выполнения при наличии в таблице нескольких записей (например, 5-7 млн). Особо объясните что произойдет при размеренности массива (у нас же массивы?) где-нибудь так 500-700.
- Приведите пример индекса, который будет использоваться при поиске.

Все это полезно продемонстрировать на каком-нибудь тестовом примере.