Stephan Szabo wrote:
>
> On Sun, 1 Oct 2000, Peter Eisentraut wrote:
>
> > Stephan Szabo writes:
> >
> > > With that, I do have a general question though. Are referential actions
> > > supposed to be limited by the permissions of the user executing the query?
> > > So, if you for example have write access on the pk table, but not to the
> > > fk table, and there is a on cascade delete relationship, should that user
> > > not be able to delete from the pk table?
> >
> > Then you could delete records that are not in relation to the foreign keys
> > in your table. So I suppose not. Of course there does seem to be a very
> > limited range of usefulness of such a setup, but we shouldn't extrapolate
> > something potentially more useful from that.
>
> Actually, I'm mostly confused about what the spec wants done. The section
> on the referential actions says things like "the rows are marked for
> deletion" without and I can't find something there that says whether or
> not you are actually supposed to pay attention to the associated privs.
I think the user deleting (or updating) the PK table must not
have DELETE or UPDATE permissions on the FK table. Another
user, who had ALTER permission for the FK table implicitly
granted that right due to the CASCADE definition.
The point is IMHO, that the user with the ALTER permission
for the FK table must have REFERENCE permission to the PK
table at the time he sets up the constraint. Otherwise, he
could insert references to all PK items without specifying
CASCADE and thus, deny operations on the PK table.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
