Точный порядок проверки constraints и запуска триггеров?

Точный порядок проверки constraints и запуска триггеров есть где-то? На стенку повесить

Вообще, столкнулся с такой проблемой:
есть таблица, содержит записи, соответствующие неким "зарегистрированным пользователям" нашей мегасистемы

таблица синхронизирована с помощью триггеров с внешним хранилищем паролей пользователей: при создании нового пользователя, удалении, изменении пароля эти изменения отражаются на внешнем хранилище (фактически через plpythonu триггером просто запускается соответствующая команда в ОС)

всё хорошо работает, кроме одной детали:
если запись пользователя попытаться удалить из таблицы, то иногда обнаруживаются ссылки на неё в других таблицах (что естественно), выдаётся ошибка (что тоже верно, стоит RESTRICT в тех таблицах), но только выдаётся эта ошибка уже после отработки триггера, который ходит во внешний мир и там также удаляет пользователя!

В результате пользователь оказывается не удалён в таблице, но удалён во внешнем хранилище

Триггер настроен на AFTER INSERT OR UPDATE OR DELETE

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

В частности вот

В частности вот здесь
http://postgresql.ru.net/manual/trigger-datachanges.html
есть интересное замечение, после пояснений по правилам видимости изменений данных:

If your trigger function is written in any of the standard procedural languages, then the above statements apply only if the function is declared VOLATILE. Functions that are declared STABLE or IMMUTABLE will not see changes made by the calling command in any case.

Возможно это оно.

триггер объявлен VOLATILE, но

триггер объявлен VOLATILE, но я не понял при чём тут это

В смысле триггерная

В смысле триггерная функция?
Так заработало правильно или нет?

Триггер сразу был объявлен

Триггер сразу был объявлен VOLATILE
Непонятно что считать правильно

Должен ли AFTER-триггер отрабатывать до проверки внешних ключей как сейчас? Или он вообще самый самый последний?

Вообще-то я считаю, что

Вообще-то я считаю, что должен, потому что какой смысл выполнять действие по удалению, если само это действие невозможно! Тогда это сильно похоже на баг.
А версия PostgreSQL какая? Последняя?

я тоже так думаю (или

в смысле, сначала проверка ключа а потом AFTER должна быть?

я надеюсь)) но не верю что никто на это ещё не напоролся
(upd: посмотрел у них на сайте и в дебиановской багзилле за сентябрь-октябрь похожего бага нет)

версия из Debian, postgresql-8.4 (8.4.1-1)

$ /usr/lib/postgresql/8.4/bin/postgres --version
postgres (PostgreSQL) 8.4.1

Самое правильное сначала

Самое правильное сначала найти порядок проверок. В гугле молчёк почему-то, видимо подразумевается что он очевиден

Полный код проблемного

Полный код проблемного участка предоставить? (куда?)

Я бы всё-таки для начала

Я бы всё-таки для начала обратился в список рассылки postgresql (английский)
Если там люди тоже скажут что баг, тогда багрепорт написать им.

ок, так и сделаю. ещё

ок, так и сделаю.

ещё интересный момент: проверка по первичному ключу отрабатывает вперёд всех триггеров (выявляется попыткой добавить существующего в таблице пользователя)

хоть бы баг, хоть бы баг! (скрестил пальцы)

Опции просмотра комментариев

Выберите предпочитаемый вами способ показа комментариев и нажмите "Сохранить настройки" для активации изменений.

Back to top

(С) Виктор Вислобоков, 2008-2023