Re: [SQL] Foreign keys breaks tables permissions

I believe the reason that the trigger does a select for update was because
otherwise there could exist a case that we select and see it and then have
the
row go away afterwards because nothing stops the delete. I could be really
wrong, but I see the scenario as the below:

If the delete happens first, the select for update waits and then knows that
the row isn't there any more and it should fail. If the select for update
happens first, the delete waits and the on delete semantics get operated.
Without the lock, one transaction could delete the row and not have the
on delete happen, because it doesn't see the inserted rows in the other
transaction and the inserting transaction thinks the child is okay because
we can see the parent, but when both commit we have a child without
a parent.

Not that that was probably terribly helpful as to how to go ahead, but...

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jan Wieck" <wieck(at)debis(dot)com>
Cc: <pgsql-hackers(at)postgresql(dot)org>; <pgsql-sql(at)postgresql(dot)org>
Sent: Thursday, May 18, 2000 4:17 PM
Subject: Re: [SQL] Foreign keys breaks tables permissions

> I looked at this some more because people were complaining that it
> was still broken in 7.0. AFAICT, it's got nothing to do with SETUID
> triggers or anything so hairy, it's just a question of what permissions
> we think ought to be required for which actions. The issue is very
> simple: the RI insert trigger doesn't do a SELECT on the master table,
> it does a SELECT FOR UPDATE --- and execMain.c thinks that that should
> require UPDATE access rights to the master.
>
> So, two questions:
>
> 1. Why is RI_FKey_check() using SELECT FOR UPDATE and not plain SELECT?
>
> 2. What permissions should SELECT FOR UPDATE require?
>
> If the existing code is correct on both these points, then I think the
> answer is that there is no bug: updating a table that has a foreign
> key reference will require update rights on the master as well. I would
> rather conclude that one of these two points is wrong...