Reverting the change will bring back the bug for which it was created. It does seem though that we have an inadequate model of how to perform permission checks. In particular, the "write" flag bit in RTEs is context dependent: it can mean insert, update, or delete permission depending on the surrounding command.
Sorry if I'm being thick, but what of this?
> regression=> insert into table1 values (1);
> NOTICE: relOid = 1245674
> NOTICE: userid = 101
> NOTICE: operation = CMD_INSERT
> NOTICE: relOid = 1245674
> NOTICE: userid = 101
> NOTICE: operation = CMD_UPDATE
> ERROR: table1: permission denied
>
> regression=> select oid, relname from pg_class where relname like 'table%';
> oid | relname
> ---------+---------
> 1245674 | table1
> 1245676 | table2
> (2 rows)
Given how rules are supposed to work, the first check looks correct: INSERT on table1 checked as pleb, userid = 101
But the second check is incorrect, not because of the mode being checked, but because of the reloid and userid. The second check should be:
UPDATE on table2 checked as postgres, userid = 1
So why doesn't the second rte refer to table2 and userid=1?
Joe
---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
