On Wednesday, April 13, 2016, Robert Haas <
robertmhaas@gmail.com> wrote:
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.
Thanks!
Stephen
