[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; G

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 SQ

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 an

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