Re: DELETE CASCADE - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: DELETE CASCADE
Date
Msg-id 316f82a9-ce30-a18a-3df8-cd42614eb701@enterprisedb.com
Whole thread Raw
In response to DELETE CASCADE  (David Christensen <david.christensen@crunchydata.com>)
Responses Re: DELETE CASCADE  (David Christensen <david.christensen@crunchydata.com>)
Re: DELETE CASCADE  (Isaac Morland <isaac.morland@gmail.com>)
List pgsql-hackers
On 03.06.21 22:49, David Christensen wrote:
> Presented for discussion is a POC for a DELETE CASCADE functionality, 
> which will allow you one-shot usage of treating existing NO ACTION and 
> RESTRICT FK constraints as if they were originally defined as CASCADE 
> constraints.  I can't tell you how many times this functionality would 
> have been useful in the field, and despite the expected answer of 
> "define your constraints right in the first place", this is not always 
> an option, nor is the ability to change that easily (or create new 
> constraints that need to revalidate against big tables) always the best 
> option.

I think, if we think this is useful, the other way around would also be 
useful: Override a foreign key defined as ON DELETE CASCADE to behave as 
RESTRICT for a particular command.




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: DELETE CASCADE
Next
From: Julien Rouhaud
Date:
Subject: Re: Are we missing (void) when return value of fsm_set_and_search is ignored?