Consenti inserimento solo dall'interno di un trigger

Sì, assolutamente possibile.

1. Generalmente non consentire UPDATE a A

Opererei con privilegi:

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

Rimangono superuser come postgres che ignorano queste umili restrizioni. Cattura quelli all'interno della tua funzione di attivazione su A con pg_has_role() :

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

Dove postgres è un vero superutente. Nota:questo cattura anche altri superutenti, dal momento che sono membri di ogni ruolo, anche di altri superutenti.

Potresti catturare i non superutenti in modo simile (in alternativa a REVOKE approccio).

2. Consenti UPDATE per ruolo demone

Crea un ruolo non di accesso, a cui è consentito aggiornare 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;

Crea funzioni trigger sulle tabelle B e C , di proprietà da questo ruolo demone e con SECURITY DEFINER . Dettagli:

• C'è un modo per disabilitare gli aggiornamenti/eliminazioni ma consentire comunque ai trigger di eseguirli?

Aggiungi alla funzione di attivazione su A :

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

Per semplici dipendenze 1:1, puoi anche lavorare con vincoli di chiave esterna (in aggiunta) utilizzando ON UPDATE CASCADE .