SET [ SESSION | LOCAL ] SESSION AUTHORIZATION nome_do_usuário
SET [ SESSION | LOCAL ] SESSION AUTHORIZATION DEFAULT
RESET SESSION AUTHORIZATION
Este comando define o identificador do usuário da sessão, e o identificador do usuário corrente, no contexto da sessão SQL corrente, como sendo o nome_do_usuário. O nome do usuário pode ser escrito tanto como um identificador quanto como um literal cadeia de caracteres. Usando este comando é possível, por exemplo, se tornar temporariamente um usuário sem privilégios e posteriormente voltar a ser um superusuário.
O identificador do usuário da sessão é inicialmente definido como sendo o (possivelmente autenticado) nome do usuário fornecido pelo cliente. O identificador do usuário corrente normalmente é igual ao identificador do usuário da sessão, mas pode mudar temporariamente no contexto das funções "setuid" e de outros mecanismos semelhantes. O identificador do usuário corrente é relevante para verificar as permissões.
O identificador do usuário da sessão somente poderá ser mudado se o usuário inicial da sessão (o usuário autenticado) possuir o privilégio de superusuário. Senão, o comando será aceito somente se especificar o nome do usuário autenticado.
Os modificadores SESSION e LOCAL atuam da mesma forma que no comando SET comum.
As formas DEFAULT e RESET redefinem os identificadores de usuário da sessão e corrente como sendo o nome do usuário autenticado originalmente. Estas formas podem ser executadas por qualquer usuário.
SELECT SESSION_USER, CURRENT_USER; session_user | current_user --------------+-------------- pedro | pedro SET SESSION AUTHORIZATION 'paulo'; SELECT SESSION_USER, CURRENT_USER; session_user | current_user --------------+-------------- paulo | paulo
O padrão SQL permite algumas outras expressões aparecerem no lugar do literal nome_do_usuário, mas estas opções não são importantes na prática. O PostgreSQL permite a sintaxe ("nome_do_usuário") para o identificador, que o SQL não permite. O padrão SQL não permite este comando durante uma transação; o PostgreSQL não faz esta restrição, porque não há razão para fazê-la. O padrão deixa os privilégios necessários para executar este comando para serem definidos pela implementação.
