A bit more about why I want this. Suppose you have an app like PostgREST (a RESTful, Haskell-coded, HTTP front-end for PostgreSQL). PostgREST basically a proxy for PG access.
Users authenticate to the proxy. The proxy authenticates to PG with its own credentials, then it does something like SET ROLE or SET SESSION AUTHORIZATION to impersonate the user to PG. Now suppose you want to support impersonation in such a proxy. That is, that user "Joe" can impersonate "Jane", for example. So what you do is you have the proxy do this: -- This is the role authenticated to the proxy: SET SESSION AUTHORIZATION <role authenticated to proxy>; -- This is the requested impersonation, and succeeds only if the first -- role has been GRANTed the second: SET SESSION ROLE <role to be impersonated by authenticated role>; Convenient! Now, if you want to... audit what Joe does, you may want to record both, the session_user (Joe) and the current_user (Jane) as you write the audit trail. Naturally, that's desirable, and it works... ...unless the audit procedures are SECURITY DEFINER. Then they don't see the current_user. They see the session_user, but can't see who the session user was impersonating. Hence I want to be able to look back through the [security definer] function invocation stack to find what current_user was at the top-level, or even just the calling function's current_user. Now, since this is a proxy, a workaround is to store the impersonated role name in an application defined GUC. But if ever you wanted to give users direct PG access (one might! it should be possible), then that's not enough because they can set that GUC. So it really has to be that the audit procedures can look up the stack. (When you give out direct PG access you really want to make those audit procedures SECURITY DEFINER, so they can do DMLs on tables that the session_user can't.) This isn't urgent _for me_, but it is a real problem. Nico -- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
