Unusual permissions behaviour

I have this problem in 7.1.3 - I can't confirm at the moment if
it exists in 7.2.

I have already granted the 'au-dietclub' user delete and insert
permissions on the users_flags table at this point:

australia=> delete from users_flags;
DELETE 0
australia=> delete from users_flags where user_id=1;
ERROR: users_flags: Permission denied.
australia=> \connect - chriskl
You are now connected as new user chriskl.
australia=# grant select on users_flags to "au-dietclub";
CHANGE
australia=# \connect - au-dietclub
You are now connected as new user au-dietclub.
australia=> delete from users_flags where user_id=1;
DELETE 0

Why do I get a permission denied when I qualify the DELETE statement???

Chris

The schema:

CREATE TABLE "users_flags" (
"user_id" integer NOT NULL REFERENCES users_users(user_id) ON DELETE
CASCADE,
"flag_id" integer NOT NULL REFERENCES medidiets_flags(flag_id) ON DELETE
CASCADE,
Primary Key ("user_id", "flag_id")
);
CREATE INDEX "users_flags_flag_id_idx" on "users_flags" using btree (
"flag_id" "
int4_ops" );

"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:

Why do I get a permission denied when I qualify the DELETE statement???

IIRC, you need SELECT permission to reference the values of any fields
of the table. If you don't have SELECT permission, the table should
be write-only to you; you shouldn't be able to learn things about its
contents by doing stuff like

begin;
delete from foo where col = 1;
-- observe # rows deleted
rollback;
-- now I know whether there is a row with col = 1

regards, tom lane