Tom, all,
On Wednesday, April 13, 2016, Tom Lane <
tgl@sss.pgh.pa.us> wrote:
Amit Langote <Langote_Amit_f8@lab.ntt.co.jp> writes:
> I observe this:
> postgres=# SET ROLE TO NONE;
> SET
> postgres=# SET ROLE TO nonexistent;
> ERROR: role "nonexistent" does not exist
> postgres=# SET ROLE TO pg_signal_backend;
> ERROR: invalid value for parameter "role": "pg_signal_backend"
> Is that behavior deliberate? Might it be better to handle the case
> specially much as setting to "none" works?
I don't think it makes sense to say the role doesn't exist when it does, in fact, exist.
What I'd like to know is why it rejects that at all. What's the point
of having roles you can't SET to?
To use them to GRANT access to other roles, which was the goal of the default roles system to begin with.
GRANT pg_signal_backend TO user1;
User1 can then send (certain) signals to other backends which it isn't a role member of.
That also avoids the issue of a default role ending up owning objects, which I don't think is desirable.
Thanks!
Stephen
