On Wed, Apr 13, 2016 at 1:24 PM, Stephen Frost <sfr...@snowman.net> wrote: > On Wednesday, April 13, 2016, Robert Haas <robertmh...@gmail.com> wrote: >> >> On Wed, Apr 13, 2016 at 1:10 PM, Stephen Frost <sfr...@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.
I don't know that there is a use case for it, but it seems like a weird inconsistency. It may be fine; it just seems odd. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
