Re: Bug / shortcoming in has_*_privilege
От | Alvaro Herrera |
---|---|
Тема | Re: Bug / shortcoming in has_*_privilege |
Дата | |
Msg-id | 1283807431-sup-3414@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Bug / shortcoming in has_*_privilege (Jim Nasby <jim@nasby.net>) |
Ответы |
Re: Bug / shortcoming in has_*_privilege
Re: Bug / shortcoming in has_*_privilege Re: Bug / shortcoming in has_*_privilege |
Список | pgsql-hackers |
Excerpts from Jim Nasby's message of jue jun 10 17:54:43 -0400 2010: > test_us@workbook=# select has_table_privilege( 'public', 'test', 'SELECT' ); > ERROR: role "public" does not exist Here's a patch implementing this idea. I'm not too sure about the wording in the doc changes. If somebody wants to propose something better, I'm all ears. To facilitate bikeshedding, here's a relevant extract: has_table_privilege checks whether a user can access a table in a particular way. The user can be specified by name; as public, to indicate the PUBLIC pseudo-role; by OID (pg_authid.oid), or, if the argument is omitted, current_user is assumed. (the first appearance of public is <literal>public</>. I had first made it <quote> but that didn't feel right.) 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. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Вложения
В списке pgsql-hackers по дате отправления: