Sim, isso é possível.

Triggers são executados com os privilégios da função trigger, padronizando para SECURITY INVOKER o que significa que a função trigger é efetivamente executada com os privilégios do current_user , no seu caso o que está inserindo linhas.

Se o usuário atual não tiver os privilégios necessários para as tabelas nas quais sua função de gatilho opera, sua operação original na tabela subjacente apresentará um erro.

No entanto , você pode usar o SECURITY DEFINER para que a função de gatilho execute esta função com os privilégios do OWNER da função.

Se você tem um superusuário próprio a função de gatilho, ela pode fazer tudo - o que seria um possível risco de segurança. Considere as instruções no manual sobre como escrever o SECURITY DEFINER Funciona com segurança.

Mas é mais sensato criar uma função simples com apenas os privilégios necessários OWNER da função de gatilho. Você pode até mesmo criar uma função "daemon" sem login, atuando como um pacote de privilégios para tais operações. Você então concederia apenas os privilégios necessários (em esquemas, tabelas, sequências...) para essa função de daemon. Para designs mais sofisticados, você deve agrupar privilégios em "funções de grupo" (novamente, sem login) e conceder essas funções de grupo às funções que precisam (para a função de daemon neste exemplo), tornando-as efetivamente "membro do grupo". Eu faço muito isso.

Considere esta resposta relacionada no dba.SE sobre os privilégios na própria função:

• Quais são os privilégios necessários para executar uma função de gatilho no PostgreSQL 8.4?