| From: | David Christensen <david(dot)christensen(at)crunchydata(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(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-04 20:24:31 |
| Message-ID: | CAOxo6XLaW15RrE5xSPwdxQGpNS2QfxSFuJ4xu-MmCL7SA2AgUQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jun 4, 2021 at 2:53 PM Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> On 03.06.21 23:47, David G. Johnston wrote:
> > This behavior should require the same permissions as actually creating
> > an ON DELETE CASCADE FK on the cascaded-to tables. i.e., Table Owner
> > role membership (the requirement for FK permissions can be assumed by
> > the presence of the existing FK constraint and being the table's owner).
>
> You can create foreign keys if you have the REFERENCES privilege on the
> primary key table. That's something this patch doesn't observe
> correctly: Normally, the owner of the foreign key table decides the
> cascade action, but with this patch, it's the primary key table owner.
>
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?
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Isaac Morland | 2021-06-04 20:40:41 | Re: DELETE CASCADE |
| Previous Message | Pavel Stehule | 2021-06-04 20:09:26 | Re: Support for CREATE MODULE? |