RE: [GENERAL] permissions & foreign keys

2000-09-04 Thread Tamsin

That's cleared that up, thanks!
Tamsin

-Original Message-
From: Jan Wieck [mailto:[EMAIL PROTECTED]]
Sent: 04 September 2000 15:50
To: Tamsin
Cc: [EMAIL PROTECTED]
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.  #
#== [EMAIL PROTECTED] #






Re: [GENERAL] permissions & foreign keys

2000-09-04 Thread Jan Wieck

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.  #
#== [EMAIL PROTECTED] #