Existe alguma vantagem funcional ou perda de desempenho ao usar RLS na tabela em vez de usar uma condição em uma exibição dessa tabela (enquanto oculta a tabela)?
Parece-me que, em vez de usar RLS em uma tabela, o que é necessário posteriormente em algumas visualizações, as visualizações podem ser limitadas em sua condição where, sem conceder nenhum acesso direto à tabela.
Existe alguma recomendação geral sobre onde escolher RLS e onde NÃO escolher RLS em favor da condição tradicional?
Estou usando segurança em nível de linha com função, por exemplo
CREATE POLICY person_select_policy ON core.person FOR SELECT USING (core.person_policy_check(id, 'read') = TRUE);
É possível passar linha inteira para a função? Assim, a função teria acesso a todas as colunas da linha sem precisar nomeá-las todas como argumentos. Dessa forma a função poderia aceitar core.personcomo parâmetro ou pelo menos um tipo de registro.
Existe uma maneira de obter o nome da função/procedimento, que contém a consulta, que causou a TRIGGERativação de um?
Por exemplo, eu tenho uma função update_user_whatevere ela atualiza os dados do usuário e quero registrar as atualizações na tabela do usuário com o conhecimento de qual função a causou (e de preferência com seus argumentos).
-- exemplo ilustrativo não testado:
CREATE FUNCTION update_user_whatever(param int) RETURNS user AS $$
UPDATE user_table SET attr=$1 RETURNING *
$$ LANGUAGE SQL;
Agora o gatilho que é executado UPDATEao executar esta função pode acessar o nome na função? (neste caso update_user_whatever)
Ou esta é uma maneira errada de olhar para o problema e uma abordagem diferente deve ser escolhida?