| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, David Christensen <david(dot)christensen(at)crunchydata(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: DELETE CASCADE |
| Date: | 2021-06-04 19:53:05 |
| Message-ID: | 31b944f1-e38b-c277-c3e2-9841cade1e0d@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2021-06-04 20:08:04 | Re: Are we missing (void) when return value of fsm_set_and_search is ignored? |
| Previous Message | Tom Lane | 2021-06-04 19:36:03 | Re: CALL versus procedures with output-only arguments |