Postgresql: o que o GRANT ALL PRIVILEGES ON DATABASE faz?

Estou tentando conceder todos os privilégios em todas as tabelas de um determinado banco de dados para um novo usuário do postgres (não o proprietário). Parece que GRANT ALL PRIVILEGES ON DATABASE my_db TO new_user;não faz isso. Depois de executar o comando com êxito (como usuário do postgres), recebo o seguinte como new_user:

$ psql -d my_db
my_db => SELECT * FROM a_table_in_my_db;
ERROR:  permission denied for relation a_table_in_my_db

Duas questões:

1) O que o comando acima faz, se não concede todas as permissões em todas as tabelas em my_db?

2) Qual é a maneira correta de conceder todas as permissões em todas as tabelas a um usuário? (inclusive em todas as tabelas criadas no futuro)

As respostas para suas perguntas vêm dos documentos on - line do PostgreSQL 8.4 .

1. GRANT ALL PRIVILEGES ON DATABASEconcede o CREATE, CONNECT, e TEMPORARYprivilégios em um banco de dados para um papel (usuários estão devidamente referidos como papéis ). Na verdade, nenhum desses privilégios permite que uma função leia dados de uma tabela; SELECTprivilégio na mesa é necessário para isso.

2. Não tenho certeza se existe uma maneira "adequada" de conceder todos os privilégios em todas as tabelas a uma função. A melhor maneira de garantir que uma determinada função tenha todos os privilégios em uma tabela é garantir que a função seja a proprietária da tabela. Por padrão, cada objeto recém-criado pertence à função que o criou; portanto, se você deseja que uma função tenha todos os privilégios em uma tabela, use essa função para criá-lo.

   O PostgreSQL 9.0 apresenta a seguinte sintaxe que é quase o que você deseja:

   GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO new_user;

   O problema é que, se você criar tabelas em esquemas fora do esquema "público" padrão, isso GRANTnão se aplicará a elas. Se você usar esquemas não públicos, terá GRANTos privilégios para esses esquemas separadamente.

É possível configurar vários logins para atuar como o proprietário do banco de dados:

• Crie uma função "nologin" para atuar como proprietário: create role dbowner nologin
• Altere o proprietário do seu banco de dados para: alter database mydb owner dbowner
• Conceda todos os seus logins a essa nova função: grant dbowner to user1, user2

Agora, se o usuário1 ou o usuário2 fizerem login, eles terão todas as permissões no "mydb", sem a necessidade de outras concessões.

No entanto, eu consideraria esta solução com cuidado. É tentador fazer com que seu aplicativo Web use um desses logons para evitar a criação de concessões adicionais sempre que o esquema for atualizado, mas você está removendo dessa forma uma forma muito útil de proteção. Use a solução acima se você realmente deseja vários "administradores", mas mantenha o padrão "conceder todos os privilégios em todas as tabelas no esquema ..." acima para o login para o aplicativo "uso normal".