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...@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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
