Re: Roles - SET ROLE Updated - Mailing list pgsql-patches

From Stephen Frost
Subject Re: Roles - SET ROLE Updated
Date
Msg-id 20050703183407.GM24207@ns.snowman.net
Whole thread Raw
In response to Roles - SET ROLE Updated  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Roles - SET ROLE Updated
List pgsql-patches
* Stephen Frost (sfrost@snowman.net) wrote:
> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
> > Stephen Frost <sfrost@snowman.net> writes:
> > > Tom, if you're watching, are you working on this?  I can probably spend
> > > some time today on it, if that'd be helpful.
> >
> > I am not; I was hoping you'd deal with SET ROLE.  Is it really much
> > different from SET SESSION AUTHORIZATION?
>
> Here's a much better version of the SET ROLE work.  I'm reasonably happy
> with it.  The only parts I don't like are that I had to do some ugly
> things in gram.y to avoid making NONE reserved, and I can't seem to see
> how to avoid having ROLE be reserved (I understand it was reserved in
> SQL99 but not in SQL2003...).

Updated yet again, fixing a bug in the prior one that caused it to not
work properly, and some additional things:

Added a 'has_role' function that's basically is_member_of_role for the
masses.  Updated information_schema to use has_role for permissions
checks in addition to the straight '=' owner-check.  Also fixed up
enabled_roles and applicable_roles views.  This depends somewhat on part
of my other patch where I modified is_member_of_role to always return
true for superuser().  If that doesn't end up being done then we'll need
to add some explicit superuser() checks in the SetCurrentRoleId() logic.

    Thanks,

        Stephen

Attachment

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: PATCH to allow concurrent VACUUMs to not lock each
Next
From: Simon Riggs
Date:
Subject: Re: Constraint Exclusion (Partitioning) - Initial Review