Grant Finnemore escreveu: > Invoking pg_stat_activity after the SET ROLE is changed will however > leave the usename unchanged. > You're right. Because, as you spotted, usename is synonym of session usename.
> SET SESSION AUTHORIZATION behaves similarly, although in that case, > it's documented that both session_user and current_user are changed > to reflect the new user. > Ugh? The manual [1][2] documents the behavior of both commands. > I have on occasion used a database pooling scheme that whenever a > connection is retrieved from the pool, either a SET ROLE or SET > SESSION AUTHORIZATION is issued to enable database level access > restrictions. Similarly, when the connection is returned, a RESET > instruction is issued. > I can't see in your use case the advantage of allowing to show current_user. > IMHO, it would be advantageous to be able to display which > connections are in use by a given user through the pg_stat_activity > view. > Isn't it embarrassing if, for example, mary queries pg_stat_activity and sees that I'm using her role, is it? I'm not against exposing this information but I think it could be superuser-only. > There are two ways in which this could be done. Firstly, we could > alter the current usename field in the view. This would keep the > view definition the same, but would alter the semantics, which could > affect existing clients. Alternatively, we could introduce another > column that would reflect the role name. > Why not add another column: current_usename? I would object if we've intended to change the view semantics. [1] http://www.postgresql.org/docs/8.3/static/sql-set-role.html [2] http://www.postgresql.org/docs/8.3/static/sql-set-session-authorization.html -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
