Да, напълно възможно.
1. Като цяло забранете АКТУАЛИЗАЦИЯ към A
Бих работил с привилегии:
REVOKE ALL ON TABLE A FROM public; -- and from anybody else who might have it
Това оставя суперпотребители като postgres които пренебрегват тези долни ограничения. Хванете тези във вашата тригерна функция на A с pg_has_role()
:
IF pg_has_role('postgres', 'member') THEN
RETURN NULL;
END IF;
Където е postgres е действителен суперпотребител. Забележка:това улавя и други суперпотребители, тъй като те са членове на всяка роля, дори на други суперпотребители.
Бихте могли да хванете не-суперпотребители по подобен начин (алтернатива на REVOKE подход).
2. Разрешете АКТУАЛИЗАЦИЯ за роля на демон
Създайте роля без влизане, която има право да актуализира A :
CREATE ROLE a_update NOLOGIN;
-- GRANT USAGE ON SCHEMA xyz TO a_update; -- may be needed, too
GRANT UPDATE ON TABLE A TO a_update;
Създайте тригерни функции на таблици B и C , собственост от тази роля на демон и с SECURITY DEFINER . Подробности:
Добавете към функцията за задействане на A :
IF pg_has_role('postgres', 'member') THEN
RETURN NULL;
ELSIF pg_has_role('a_update', 'member') THEN
RETURN NEW;
END IF;
За прости зависимости 1:1 можете също да работите с ограничения на чужд ключ (допълнително) с помощта на ON UPDATE CASCADE
.
