Re: SET ROLE and reserved roles

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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:24:53
Message-ID: CAOuzzgrMW1Vgpyw1Q1F0q1NgqMp45WW=3Sg-8p6zqT2z5Dq=Qw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wednesday, April 13, 2016, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Wed, Apr 13, 2016 at 1:10 PM, Stephen Frost <sfrost(at)snowman(dot)net
> <javascript:;>> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message reiner peterke 2016-04-13 17:25:02 Re: Problems with huge_pages and IBM Power8
Previous Message Andres Freund 2016-04-13 17:19:55 Re: Re: [COMMITTERS] pgsql: Avoid extra locks in GetSnapshotData if old_snapshot_threshold <