Skip site navigation (1) Skip section navigation (2)

Re: Bug / shortcoming in has_*_privilege

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: Jim Nasby <jim(at)nasby(dot)net>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Bug / shortcoming in has_*_privilege
Date: 2010-10-06 17:05:09
Message-ID: 1286384540-sup-9594@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Excerpts from KaiGai Kohei's message of mar oct 05 00:06:05 -0400 2010:
> (2010/09/07 6:16), Alvaro Herrera wrote:
> > Excerpts from Jim Nasby's message of jue jun 10 17:54:43 -0400 2010:
> >> test_us(at)workbook=# select has_table_privilege( 'public', 'test', 'SELECT' );
> >> ERROR:  role "public" does not exist
> > 
> > Here's a patch implementing this idea.
> > 
> I checked this patch.

Thanks.

> It seems to me it replaces whole of get_role_oid() in has_*_privilege
> functions by the new get_role_oid_or_public(), so this patch allows
> to accept the pseudo "public" user in consistent way.

Yes.

> The pg_has_role_*() functions are exception. It will raise an error
> with error message of "role "public" does not exist".
> Is it an expected bahavior, isn't it?

Yes.  You cannot grant "public" to roles; according to the definition of
public, this doesn't make sense.  Accordingly, I chose to reject
"public" as an input for pg_has_role and friends.

> > Another thing that could raise eyebrows is that I chose to remove the
> > "missing_ok" argument from get_role_oid_or_public, so it's not a perfect
> > mirror of it.  None of the current callers need it, but perhaps people
> > would like these functions to be consistent.
> > 
> Tom Lane suggested to add missing_ok argument, although it is not a must-
> requirement.

Actually I think he suggested the opposite.

-- 
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-10-06 17:40:27
Subject: Re: patch: tsearch - some memory diet
Previous:From: Robert HaasDate: 2010-10-06 16:50:29
Subject: Re: standby registration (was: is sync rep stalled?)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group