Einfügen nur innerhalb eines Triggers zulassen

Ja, durchaus möglich.

1. Allgemein verbieten UPDATE zu A

Ich würde mit Privilegien arbeiten:

REVOKE ALL ON TABLE A FROM public;  -- and from anybody else who might have it

Übrig bleiben Superuser wie postgres die diese niedrigen Beschränkungen ignorieren. Fangen Sie diese in Ihrer Trigger-Funktion auf A mit pg_has_role() :

IF pg_has_role('postgres', 'member') THEN
   RETURN NULL;
END IF;

Wobei postgres ist ein echter Superuser. Hinweis:Dies erfasst auch andere Superuser, da sie Mitglied jeder Rolle sind, sogar anderer Superuser.

Sie könnten Nicht-Superuser auf ähnliche Weise abfangen (alternativ zum REVOKE Ansatz).

2. UPDATE zulassen für Daemon-Rolle

Erstellen Sie eine Nicht-Login-Rolle, die A aktualisieren darf :

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;

Erstellen Sie Triggerfunktionen für die Tabellen B und C , im Besitz durch diese Daemon-Rolle und mit SECURITY DEFINER . Einzelheiten:

• Gibt es eine Möglichkeit, Aktualisierungen/Löschvorgänge zu deaktivieren, aber dennoch Auslösern zu erlauben, sie auszuführen?

Fügen Sie die Triggerfunktion auf A hinzu :

IF pg_has_role('postgres', 'member') THEN
   RETURN NULL;
ELSIF pg_has_role('a_update', 'member') THEN
   RETURN NEW;
END IF;

Für einfache 1:1-Abhängigkeiten können Sie auch mit Fremdschlüsseleinschränkungen (zusätzlich) mit ON UPDATE CASCADE .