Re: SET ROLE and reserved roles
| От | Stephen Frost |
|---|---|
| Тема | Re: SET ROLE and reserved roles |
| Дата | |
| Msg-id | CAOuzzgrMW1Vgpyw1Q1F0q1NgqMp45WW=3Sg-8p6zqT2z5Dq=Qw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: SET ROLE and reserved roles (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: SET ROLE and reserved roles
Re: SET ROLE and reserved roles |
| Список | pgsql-hackers |
On Wednesday, April 13, 2016, Robert Haas <robertmhaas@gmail.com> wrote:
Thanks!
On Wed, Apr 13, 2016 at 1:10 PM, Stephen Frost <sfrost@snowman.net> wrote:
>> 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.
Well ... yeah. But that doesn't mean it should be impossible to SET
to that role itself. I'm a little worried that could create strange
corner cases.
Being able to create objects owned by a default role was one of those strange corner cases I was trying to avoid.
What's the use-case for setting to the role..? I would generally argue that it's actually to create objects as that role, which is something I believe we specifically do not want for default roles, and in some limited cases to drop or gain additional privileges, when using noinherit roles (which are not the default). The latter can still be accomplished, of course, by creating a role which is noinherit and using that.
Stephen
В списке pgsql-hackers по дате отправления: