Devido à reescrita dos comandos pelo sistema de regras do PostgreSQL, são acessadas outras tabelas e visões além daquelas utilizadas no comando original. Quando são utilizadas regras de atualização, pode incluir o acesso de escrita na tabela.
As regras de reescrita não possuem um dono em separado. O dono da relação (tabela ou visão) é automaticamente o dono das regras de reescrita definidas para a relação. O sistema de regras do PostgreSQL altera o comportamento do sistema de controle de acesso padrão. As relações utilizadas devido às regras são verificadas com relação aos privilégios do dono da regra, e não do usuário chamando a regra. Isto significa que o usuário só precisa ter os privilégios requeridos pelas tabelas e visões explicitamente nomeadas em seus comandos.
Por exemplo: Um usuário que possua uma lista de números de telefone onde alguns são particulares e outros são de interesse da secretária do escritório, poderá definir o seguinte esquema:
CREATE TABLE tbl_telefone (pessoa text, telefone text, particular boolean);
CREATE VIEW vis_telefone AS
SELECT pessoa, telefone FROM tbl_telefone WHERE NOT particular;
GRANT SELECT ON vis_telefone TO secretaria;
Assim, ninguém exceto ele próprio (e os superusuários do banco de dados) pode acessar a tabela tbl_telefone, mas por causa do GRANT a secretária pode executar o SELECT na visão vis_telefone. O sistema de regras reescreve o SELECT da visão vis_telefone em um SELECT da tabela tbl_telefone, e adiciona a qualificação que são desejadas apenas as linhas onde particular é falso. Uma vez que o usuário é o dono da visão vis_telefone e, portanto, o dono da regra, o acesso de leitura para a tabela tbl_telefone agora é verificado com relação aos privilégios do usuário, e o comando é permitido. A verificação do privilégio para acessar a visão vis_telefone também é feita, mas com relação ao usuário que acessa a visão e, portanto, ninguém além do próprio usuário e a secretária pode utilizá-la.
Os privilégios são verificados regra por regra. Portanto, agora só a secretária pode ver os números de telefone públicos. Mas a secretária pode definir uma outra visão, e permitir o acesso público a mesma. Assim, todo mundo vai poder ver os dados de vis_telefone através da visão da secretária. O que a secretária não pode fazer é criar uma visão com acesso direto à tabela tbl_telefone (Na verdade pode, mas não funciona porque todos os acessos serão negados durante a verificação de permissão). Tão logo o usuário perceba que a secretária abriu sua visão vis_telefone ele pode revogar o acesso. Imediatamente todos os acessos à visão da secretária vão falhar.
Pode-se pensar que esta verificação regra por regra é um furo de segurança, mas na verdade não é. Se não funcionasse desta maneira a secretária poderia definir uma tabela com as mesmas colunas de vis_telefone, e copiar os dados para esta tabela uma vez por dia. Então seriam seus próprios dados, e a secretária poderia conceder acesso a todos que desejasse. Um comando GRANT significa "Eu confio em você". Se alguém em que você confia faz uma coisa desta, é hora de repensar e utilizar o comando REVOKE.
Este mecanismo também funciona para as regras de atualização. Nos exemplos da seção anterior, o dono das tabelas no banco de dados de exemplo poderia conceder para outro usuário os privilégios SELECT, INSERT, UPDATE e DELETE na visão vis_cadarço, e somente o privilégio SELECT na tabela tbl_cadarço_log. A ação da regra para escrever registros de acompanhamento ainda será executada com sucesso, e o outro usuário vai poder ver os registros de acompanhamento, mas se alguém criar registros falsos este não vai poder manipular nem remover estes registros falsos.
