On Wednesday, June 9, 2021, Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote:
> > It might work, I'm just saying it needs to be thought about carefully. If > you have functionality like, delete this if there is no matching record > over there, you need to have the permission to check that and need to make > sure it stays that way. > > Which I believe the presence of an existing foreign key does quite nicely. Thus if the executing user is the table owner (group membership usually) and a FK already exists, the conditions for the cascade are fulfilled, including locking I would think, because that FK could have been defined to just do it without all this. We are effectively just temporarily changing that aspect of the foreign key - the behavior should be identical to on cascade delete. I require convincing that there is a use case that requires laxer permissions. Especially if we can solve the whole changing of the cascade option without having to drop the foreign key. David J.
