Re: DELETE CASCADE - Mailing list pgsql-hackers

From David Christensen
Subject Re: DELETE CASCADE
Date
Msg-id CAOxo6XJ9jHMFZQ03Ji9_TLj7JhuADz6JPr65VDUNAccgVBPoMg@mail.gmail.com
Whole thread Raw
In response to Re: DELETE CASCADE  (David Christensen <david.christensen@crunchydata.com>)
Responses Re: DELETE CASCADE  (Isaac Morland <isaac.morland@gmail.com>)
List pgsql-hackers
What happens if I don't have delete permission on the referencing table? When a foreign key reference delete cascades, I can cause records to disappear from a referencing table even if I don't have delete permission on that table. This feels like it's just supposed to be a convenience that replaces multiple DELETE invocations but one way or the other we need to be clear on the behaviour.

Did you test this and find a failure? Because it is literally using all of the same RI proc code/permissions as defined I would expect that it would just abort the transaction.  (I am working on expanding the test suite for this feature to allow for test cases like this, so keep 'em coming... :-))

Enclosed is a basic test script and the corresponding output run through `psql -e` (will adapt into part of the regression test, but wanted to get this out there).  TL;DR; DELETE CASCADE behaves exactly as if said constraint were defined as a ON DELETE CASCADE FK constraint wrt DELETE permission behavior.  I do agree in this case, that it makes sense to throw an error if we're trying to bypass the RESTRICT behavior and we are not part of the table owner role (and since this would be called/checked recursively for each table involved in the graph I think we can count on it reporting the appropriate error message in this case).


Attachment

pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: DELETE CASCADE
Next
From: Isaac Morland
Date:
Subject: Re: DELETE CASCADE