Re: DELETE CASCADE - Mailing list pgsql-hackers

From David Christensen
Subject Re: DELETE CASCADE
Date
Msg-id 28EA43CF-22BE-4727-A201-AFBDA06CE7B5@crunchydata.com
Whole thread Raw
In response to Re: DELETE CASCADE  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: DELETE CASCADE  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
> On Jun 5, 2021, at 2:30 AM, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
>
> 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
treatingexisting NO ACTION and RESTRICT FK constraints as if they were originally defined as CASCADE constraints.  I
can'ttell you how many times this functionality would have been useful in the field, and despite the expected answer of
"defineyour 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
DELETECASCADE to behave as RESTRICT for a particular command. 

I am not opposed to this, but I am struggling to come up with a use case. Where would this be useful?

David


pgsql-hackers by date:

Previous
From: Abbas Butt
Date:
Subject: Logical replication keepalive flood
Next
From: Isaac Morland
Date:
Subject: Re: DELETE CASCADE