Re: [HACKERS] "CURRENT_ROLE" is not documented - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] "CURRENT_ROLE" is not documented
Date
Msg-id alpine.DEB.2.20.1705061934560.3896@lancre
Whole thread Raw
In response to Re: [HACKERS] "CURRENT_ROLE" is not documented  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] "CURRENT_ROLE" is not documented
List pgsql-hackers
>>   psql> SELECT CURRENT_ROLE;
>>     current_user -- not a typo, it really says "current_user"
>
> Not as of HEAD ;-)

Good:-) I was connecting to a 9.6.2 server from a pg10dev client.

>> Is there a special reason why it does not appear in the documentation?
>
> Oversight, evidently.

Ok.

>> 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.

Hmmm... why not. I'm in the pg context where a USER is a ROLE, as you 
point out below.

> 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.

Yep.

> I agree we ought to document this, but we likely need to mention
> the discrepancy from the spec, too.

Yep. A little subtle, though. Maybe it is enough to just say that for pg a 
user is a role, which is not the case in the standard?

Thanks for the explanation!

-- 
Fabien.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Draft release notes for next week's back-branch releases
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] "CURRENT_ROLE" is not documented