PostgreSQL
 sql >> Base de Dados >  >> RDS >> PostgreSQL

Permitir inserção apenas de dentro de um gatilho


Sim, totalmente possível.

1. Geralmente não permite UPDATE para A


Eu operaria com privilégios:
REVOKE ALL ON TABLE A FROM public;  -- and from anybody else who might have it

Isso deixa superusuários como postgres que ignoram essas restrições humildes. Pegue aqueles dentro de sua função de gatilho em A com pg_has_role() :
IF pg_has_role('postgres', 'member') THEN
   RETURN NULL;
END IF;

Onde postgres é um superusuário real. Nota:isso também pega outros superusuários, já que eles são membros de todas as funções, até mesmo outros superusuários.

Você pode capturar não superusuários de maneira semelhante (alternativa ao REVOKE abordagem).

2. Permitir UPDATE para função de daemon


Crie uma função sem login, que tenha permissão para atualizar 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;

Crie funções de gatilho nas tabelas B e C , de propriedade por esta função de daemon e com SECURITY DEFINER . Detalhes:

Adicionar à função de gatilho em A :
IF pg_has_role('postgres', 'member') THEN
   RETURN NULL;
ELSIF pg_has_role('a_update', 'member') THEN
   RETURN NEW;
END IF;

Para dependências 1:1 simples, você também pode trabalhar com restrições de chave estrangeira (adicionalmente) usando ON UPDATE CASCADE .