RE: permissions & foreign keys

From: "Tamsin" <tg_mail(at)bryncadfan(dot)co(dot)uk>
To: "Jan Wieck" <janwieck(at)Yahoo(dot)com>
Cc: "Pgsql-General(at)Postgresql(dot)Org" <pgsql-general(at)postgresql(dot)org>
Subject: RE: permissions & foreign keys
Date: 2000-09-04 13:51:08
Message-ID: NEBBKHBOBMJCHDMGKCNJAEPDCCAA.tg_mail@bryncadfan.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

That's cleared that up, thanks!
Tamsin

-----Original Message-----
From: Jan Wieck [mailto:janwieck(at)Yahoo(dot)com]
Sent: 04 September 2000 15:50
To: Tamsin
Cc: Pgsql-General(at)Postgresql(dot)Org
Subject: Re: [GENERAL] permissions & foreign keys

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 #

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Jan Wieck 2000-09-04 14:49:38 Re: permissions & foreign keys
Previous Message cuke 2000-09-04 13:43:37 To: He Weiping Laser Henry