авторВопрос такой.
Если дать такой запрос:
update SCHEMES set ID = 99 where ID = 12;
то в проведенных документах ID_SCH изменится, или изменение в SCHEMES не пройдет, или в SCHEMES пройдет, но в документах только непроведенных ID_SCH изменится ?

Я не поленился и поставил эксперимент. Получается, что ID_SCH измениться только в непроведенных документах. Удивительно, что в результате база данных приходит в несогласованное состояние: в таблице DOCUMENTS появляются записи, для которых нет соответствующих в таблице SCHEMES. Если теперь удалить внешний ключ, то создать его снова не удастся. Если сделать backup то при восстановлении так же будут проблемы.
Если удалить правило, запрещающее update, то эти "плохие" строки все равно нельзя будет изменять, потому что происходит нарушение ограничения foregn key.
Плохо, что не удалось заставить postgres проверить выполнение foregn key для _существующих_ строк и как то отловить эту ситуацию (при создании внешнего ключа отложенные проверки не использовались). Я думал, что база всегда находится в согласованном состоянии, а теперь возникает вопрос "как проверять целостность?"

Думаю, нужно подождать комментария гуру.

To strizh:
Мне кажется самое простое решение для вашей задачи, это создать представление на таблицу DOCUMENTS, на неё навесить правило, запрещающее обновление проведенных документов и отдать её юзеру.

strizh
подменить таблицу представлением - это хорошая идея. Только при этом надо в клиентском интерфейсе везде менять имя DOCUMENTS на DOCUMENTS_V. А этого никому делать не хочется. Да и судя по категоричности assa - рули все одно кривые, и их надо бы избегать.


Можно не переделывать клиентские приложения, если данные перенести в новую таблицу DOCUMENTS_DATA, а представление на эту таблицу назвать DOCUMENTS. Что касается RULE, то вместо него можно использовать триггер. Это непринципиально.

автор
У меня идея была поступить по-простому. В запрещающем триггере проверять еще и имя юзера. И если это владелец базы - то только ему позволять все обновления (в том числе которые по update cascade идут), в том числе проведенных документов. Но это ж тогда юзерам неудобно. Кто-то схему поменял (у меня в базе еще несколько таких мест есть - артикулы шведского производителя, к примеру, которые изредка меняются по присылаемой оттуда таблице соответствия) - а бежать менять надо к админу - бо только он сможет. Неправильно это как-то.
Кажется, это называется Row-Level Security (RLS).
Есть статья по этому поводу. Для Постгреса стандартных стредств нет, обычно проблему решают с помощью создания представлений и раздачей прав на них. RLS просто позволяет избежать лишних хлопот (представления нужно как-то называть, вручную раздавать права, и если пользователей много, то это неудобно).