Fwd: Bug with groups and access permissions (7.0.0RC1): more information

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