Re: Roles - SET ROLE Updated

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Roles - SET ROLE Updated
Date: 2005-07-21 19:57:50
Message-ID: 20050721195750.GF24207@ns.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Another issue: I like the has_role() function and in fact think it needs
> to come in multiple variants just like has_table_privilege and friends:
>
> has_role(name, name)
> has_role(name, oid)
> has_role(oid, name)
> has_role(oid, oid)
> has_role(name) -- implicitly has_role(current_user, ...)
> has_role(oid)
>
> However I'm a bit dubious about whether "has_role" isn't an invasion of
> application namespace. pg_has_role would be better, but we have the
> (mis) precedent of has_table_privilege. What do you think about calling
> it "has_role_privilege"?

I thought about that originally. It seemed a bit long to me and I felt
that having the 'privilege' of a role wasn't quite the same as having a
'role', but honestly I'm not terribly picky and on reflection a role
*is* like other objects in the catalog (I originally hadn't considered
it such), so, that's fine with me...

has_role() was another reason I was thinking about having a seperate
function for 'is_member_of_role' which didn't pollute the cache, just a
side-note.

Thanks,

Stephen

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-07-21 20:30:06 Re: [PATCHES] Roles - SET ROLE Updated
Previous Message Stephen Frost 2005-07-21 19:54:59 Re: Roles - SET ROLE Updated

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-07-21 20:30:06 Re: [PATCHES] Roles - SET ROLE Updated
Previous Message Stephen Frost 2005-07-21 19:54:59 Re: Roles - SET ROLE Updated