From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: SET ROLE and reserved roles |
Date: | 2016-04-13 17:10:02 |
Message-ID: | CAOuzzgoLOeKTwuVkj8Dw0PVVSHS7kF0GPg33ARzPZFtJDZ9gzQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom, all,
On Wednesday, April 13, 2016, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp <javascript:;>> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2016-04-13 17:16:02 | Re: SET ROLE and reserved roles |
Previous Message | Robert Haas | 2016-04-13 17:03:26 | Re: Incomplete startup packet errors |