Re: DELETE CASCADE - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: DELETE CASCADE
Date
Msg-id 31b944f1-e38b-c277-c3e2-9841cade1e0d@enterprisedb.com
Whole thread Raw
In response to Re: DELETE CASCADE  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: DELETE CASCADE  (David Christensen <david.christensen@crunchydata.com>)
List 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.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: CALL versus procedures with output-only arguments
Next
From: Peter Eisentraut
Date:
Subject: Re: Are we missing (void) when return value of fsm_set_and_search is ignored?