はい、完全に可能です。
1。通常、 UPDATEは許可されません 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。 UPDATEを許可する デーモンの役割の場合
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 、所有 このデーモンの役割とSECURITYDEFINER 。詳細：
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 を使用した外部キー制約（追加）
。