[HACKERS] another roles related question

2005-07-09 Thread Joe Conway
Roles cause a problem for the information schema view table_privileges. For example: CREATE TABLE tbl_1 ( f1int, f2text ); INSERT INTO tbl_1 VALUES(1, 'a'); REVOKE ALL ON tbl_1 FROM public; CREATE USER user1; CREATE USER user2; CREATE ROLE role1; GRANT ALL ON tbl_1 TO role1;

Re: [HACKERS] another roles related question

2005-07-09 Thread Stephen Frost
* Joe Conway ([EMAIL PROTECTED]) wrote: Roles cause a problem for the information schema view table_privileges. Right. [...] Is this something we should worry about? Or do we just put a warning in the docs? I've already submitted a patch which should correct this. It also adds a new SQL

Re: [HACKERS] another roles related question

2005-07-09 Thread Joe Conway
Stephen Frost wrote: Is this something we should worry about? Or do we just put a warning in the docs? I've already submitted a patch which should correct this. It also adds a new SQL function which determines if a given user is in a specific role. It also implements SET ROLE, CURRENT_ROLE

Re: [HACKERS] another roles related question

2005-07-09 Thread Stephen Frost
* Joe Conway ([EMAIL PROTECTED]) wrote: Stephen Frost wrote: I've already submitted a patch which should correct this. It also adds a new SQL function which determines if a given user is in a specific role. It also implements SET ROLE, CURRENT_ROLE and SYSTEM_USER. Oh, cool. Sorry for the