Well, I have more information about theses bugs:
> It seems there is a 'referential integrity' bug with groups and permissions:
>
> db=> CREATE USER user1;
> CREATE USER
> db=> CREATE GROUP group1 WITH SYSID 4 USER user1;
> CREATE GROUP
> db=> CREATE TABLE table1 (field1 integer PRIMARY KEY);
> CREATE
> db=> REVOKE ALL ON table1 FROM PUBLIC;
> CHANGE
> db=> GRANT ALL ON table1 TO GROUP group1;
> CHANGE
> db=> DROP GROUP group1;
> DROP GROUP
> \z
> NOTICE: get_groname: group 4 not found
> The connection to the server was lost. Attempting reset: Failed.
> !=>
It seems that dropping the group don't delete it from the tables permissions
(acl).
Then, when Postgresql try to display them, it can't find the name of the dropped
group.
> db=> DROP USER userx;
> ERROR: group groupy does not exist.
> db=> SELECT * from PG_GROUP;
> ...
> groupy | 5 | {1,4}
> ...
> db=> DROP GROUP groupy;
> DROP
>
Apparently, this tied with databases:
- Create a group 'foo' in the database 'foodb':
\c foodb postgres
CREATE GROUP foo;
- Add the user 'userfoo' in this group:
ALTER GROUP foo ADD USER 'userfoo;'
- Reconnect to database 'bardb':
\c bardb
- Trying to drop the user 'userfoo' leads to "group foo does not exist":
DROP USER userfoo;
But either dropping 'userfoo' from 'foodb' or dropping group 'foo' from 'bardb'
works!
Guillaume Perréal - Stagiaire MIAG
Cemagref (URH), Lyon, France
Tél: (+33) 4.72.20.87.64