Fabien COELHO <coelho@cri.ensmp.fr> writes:
> While trying to understand whether there was any difference, I noticed
> that CURRENT_ROLE is an undocumented synonymous for CURRENT_USER:
> psql> SELECT CURRENT_ROLE;
> current_user -- not a typo, it really says "current_user"
Not as of HEAD ;-)
> Is there a special reason why it does not appear in the documentation?
Oversight, evidently.
> Also, there is a SESSION_USER, but no SESSION_ROLE. Not sure of the
> rationale.
SQL standard says so, basically. The standard draws a hard line between
"role" and "user", and says that only "users" can be the initiators of
sessions, so that the initial privilege identifier is always a user name
not a role name; hence no need for SESSION_ROLE.
It looks to me like according to the spec, when the current privilege
identifier is a role name, then CURRENT_ROLE returns that name and
CURRENT_USER returns NULL; when the current privilege identifier is a
user name, the opposite is true.
PG doesn't draw such a hard line; for us, roles and users are the same
kind of entity, with the distinction being a can-login privilege that's
really only a minor attribute. So I think it's sensible for us to
treat these functions as synonyms.
Perhaps we could satisfy the letter of the spec by having one of these
functions return NULL depending on the current role's can-login attribute,
but I frankly cannot see a reason why that would be a good thing to do.
It would mostly be a foot-gun for SQL queries --- I think you'd basically
always have to write "coalesce(current_user, current_role)" to avoid
having your code break in unexpected contexts.
I agree we ought to document this, but we likely need to mention
the discrepancy from the spec, too.
regards, tom lane