--On Mittwoch, August 27, 2008 09:35:03 +0200 Grant Finnemore
[EMAIL PROTECTED] wrote:
I have a session pool, where all connections to the database are
obtained as a superuser. On issuing connections to the client, we
invoke either SET ROLE or SET SESSION AUTHORIZATION and switch to
a role
Hi Bernd,
Bernd Helmle wrote:
--On Mittwoch, August 27, 2008 09:35:03 +0200 Grant Finnemore
[EMAIL PROTECTED] wrote:
I have a session pool, where all connections to the database are
obtained as a superuser. On issuing connections to the client, we
invoke either SET ROLE or SET SESSION
Grant Finnemore wrote:
Well, pg_stat_activity isn't really the problem here, because as you
point out, it's just a view, and I could certainly redefine the view.
The limiting factor is that the backend doesn't push the role name
changes to the stats subsystem for either SET ROLE or SET
Hi Alvaro,
Alvaro Herrera wrote:
Grant Finnemore wrote:
Well, pg_stat_activity isn't really the problem here, because as you
point out, it's just a view, and I could certainly redefine the view.
The limiting factor is that the backend doesn't push the role name
changes to the stats subsystem
Hi Euler,
Euler Taveira de Oliveira wrote:
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.
The one problem with this mapping is that per
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
Hi,
In the manual for SET ROLE, it's noted that an invocation of SET ROLE
will leave the session_user unchanged, but will change the current_user.
Invoking pg_stat_activity after the SET ROLE is changed will however
leave the usename unchanged. (Also from the manual we note that a
snapshot is
