From: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | David Christensen <david(dot)christensen(at)crunchydata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DELETE CASCADE |
Date: | 2021-06-09 13:48:00 |
Message-ID: | CAKFQuwabcO4ikW9wh4ci2KjtREB9K_kSx1dZvpvgcfHbDfjxxA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wednesday, June 9, 2021, Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2021-06-09 13:55:08 | Re: Fix dropped object handling in pg_event_trigger_ddl_commands |
Previous Message | Dilip Kumar | 2021-06-09 13:46:39 | Re: Decoding speculative insert with toast leaks memory |