| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | David Christensen <david(dot)christensen(at)crunchydata(dot)com> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: DELETE CASCADE |
| Date: | 2021-06-07 07:56:49 |
| Message-ID: | c5592dce-3a5a-4285-7889-f3534d9d794c@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 05.06.21 14:25, David Christensen wrote:
>
>> On Jun 5, 2021, at 2:29 AM, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>>
>> On 04.06.21 22:24, David Christensen wrote:
>>> So what are the necessary and sufficient conditions to check at this point? The constraint already exists, so what permissions would we need to check against which table(s) in order to grant this action?
>>
>> I think you would need DELETE privilege on all affected tables.
>
> So basically where we are dispatching to the CASCADE guts, first check session user’s DELETE permission and throw the normal permissions error if they can’t delete?
Actually, you also need appropriate SELECT permissions that correspond
to the WHERE clause of the DELETE statement.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Nancarrow | 2021-06-07 08:20:48 | Re: [HACKERS] logical decoding of two-phase transactions |
| Previous Message | Tatsuro Yamada | 2021-06-07 07:54:49 | Re: Duplicate history file? |