| From: | Jan Wieck <janwieck(at)Yahoo(dot)com> |
|---|---|
| To: | Tamsin <tg_mail(at)bryncadfan(dot)co(dot)uk> |
| Cc: | "Pgsql-General(at)Postgresql(dot)Org" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: permissions & foreign keys |
| Date: | 2000-09-04 14:49:38 |
| Message-ID: | 200009041449.JAA02302@jupiter.jw.home |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Tamsin wrote:
>
> I don't really see why it wants to update feedback_type? Can anyone tell me
> what I'm doing wrong, or will I just have to grant update on feedback_type
> (and all other tables referenced by FKs)?
>
It doesn't want to update it. It just does the SELECT ... FOR
UPDATE to lock the now referenced row. Doing it without a
lock would make it possible, that just after your backend
checked that the PK row exists but before you got a chance to
commit, another backend could delete that PK without seeing
your just inserted reference. End would be a violated FK
constraint.
The bug here is, that doing a SELECT ... FOR UPDATE already
requires UPDATE permissions. The correct solution would be to
require a REFERENCES privilege for the owner of the
referencing table. But we don't have that up to now.
Maybe I can do something about it for 7.1.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Enrico Comini | 2000-09-04 15:06:10 | test3 |
| Previous Message | Tamsin | 2000-09-04 13:51:08 | RE: permissions & foreign keys |