Re: SET ROLE and reserved roles
| От | Stephen Frost |
|---|---|
| Тема | Re: SET ROLE and reserved roles |
| Дата | |
| Msg-id | CAOuzzgoLOeKTwuVkj8Dw0PVVSHS7kF0GPg33ARzPZFtJDZ9gzQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SET ROLE and reserved roles (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: SET ROLE and reserved roles
Re: SET ROLE and reserved roles |
| Список | pgsql-hackers |
Tom, all,
On Wednesday, April 13, 2016, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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
В списке pgsql-hackers по дате отправления: