Tom Lane wrote:
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"?
Do we need to follow a bad prec
* Tom Lane ([EMAIL PROTECTED]) wrote:
> However, on second thought I'm not sure that this is sensible anyway.
>
> Consider that every role is implicitly a member of PUBLIC --- so isn't
> the above a creation of a circular membership loop, which is (for good
> reason) forbidden by the spec?
Ah, ye
* Tom Lane ([EMAIL PROTECTED]) 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, oi
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) -- implic
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> BTW, I realized we do not support granting roles to PUBLIC:
>>
>> regression=# create role r;
>> CREATE ROLE
>> regression=# grant r to public;
>> ERROR: role "public" does not exist
>>
>> but as far as I can
* Tom Lane ([EMAIL PROTECTED]) wrote:
> BTW, I realized we do not support granting roles to PUBLIC:
>
> regression=# create role r;
> CREATE ROLE
> regression=# grant r to public;
> ERROR: role "public" does not exist
>
> but as far as I can tell SQL99 expects this to work.
Indeed, I believe yo
BTW, I realized we do not support granting roles to PUBLIC:
regression=# create role r;
CREATE ROLE
regression=# grant r to public;
ERROR: role "public" does not exist
but as far as I can tell SQL99 expects this to work.
regards, tom lane
---(end
Stephen Frost <[EMAIL PROTECTED]> writes:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
>> After rereading SQL99 4.31, I don't think there is any need to
>> distinguish CURRENT_USER from CURRENT_ROLE, mainly because our
>> implementation does not distinguish users from roles at all.
> CURRENT_USER and C
* Tom Lane ([EMAIL PROTECTED]) wrote:
> After rereading SQL99 4.31, I don't think there is any need to
> distinguish CURRENT_USER from CURRENT_ROLE, mainly because our
> implementation does not distinguish users from roles at all.
CURRENT_USER and CURRENT_ROLE can have different values, as I under
Stephen Frost <[EMAIL PROTECTED]> writes:
>> 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 res
* Stephen Frost ([EMAIL PROTECTED]) wrote:
> * Tom Lane ([EMAIL PROTECTED]) wrote:
> > Stephen Frost <[EMAIL PROTECTED]> 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 dea
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> 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 SE
* Tom Lane ([EMAIL PROTECTED]) wrote:
> Stephen Frost <[EMAIL PROTECTED]> 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 SE
13 matches
Mail list logo
