Permitir la inserción solo desde dentro de un disparador

Sí, totalmente posible.

1. Generalmente deshabilitar UPDATE a A

Operaría con privilegios:

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

Eso deja a los superusuarios como postgres que ignoran estas humildes restricciones. Atraparlos dentro de su función de activación en A con pg_has_role() :

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

Donde postgres es un superusuario real. Nota:esto también afecta a otros superusuarios, ya que son miembros de todos los roles, incluso otros superusuarios.

Podría atrapar a los no superusuarios de una manera similar (alternativa a REVOKE enfoque).

2. Permitir UPDATE para el rol de demonio

Cree un rol de no inicio de sesión, que puede actualizar 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;

Crear funciones de activación en las tablas B y C , propiedad por este rol de daemon y con SECURITY DEFINER . Detalles:

• ¿Hay alguna forma de deshabilitar las actualizaciones/eliminaciones pero aún permitir que los activadores las realicen?

Agregar a la función de activación en A :

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

Para dependencias simples 1:1, también puede trabajar con restricciones de clave externa (adicionalmente) usando ON UPDATE CASCADE .