Re: Cascade delete triggers change user credentials

Stephan Szabo wrote:
> The triggered actions occur as if done by the owner of the fktable so that
> they will not fail if the current user does not actually have delete
> access on that table. I'm not sure which result for current_user makes
> more sense in that context for further triggered actions.

and Tom Lane added:
> I would suggest that Antonios probably really wants to be using
> SESSION_USER, not CURRENT_USER.

Thank you very much, this explains it all. session_user works as I
want it to. However, the manual is not very clear on this, and I'm a bit
worried about future changes in the semantics of "session_user".

In PostgreSQL there are actually up to THREE users active, not two:
- The user who connected, which I shall call "connected user".
- The user who became effective as the result of "alter session
authorization" command. This is the user returned by session_user.
- The user who is applicable for permission checking, current_user.

If you try to "alter session authorization", PostgreSQL uses the
"connected user" to determine whether you have permission to do so (or,
at least, remembers that you initially connected as superuser). The
current user is used in most other cases of permission checking.

The 7.4 manual, however, says that the session_user "is the user that
initiated a database connection", and fails to mention "alter session
authorization". Is the manual in error or the implementation? Because my
triggers need to know which user became effective after "alter session
authorization". This is "session_user" in 7.2.1, is it still so in 7.4?
Will it still be so in the future?