| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | David Christensen <david(dot)christensen(at)crunchydata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: DELETE CASCADE |
| Date: | 2021-06-05 07:30:42 |
| Message-ID: | 316f82a9-ce30-a18a-3df8-cd42614eb701@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Julien Rouhaud | 2021-06-05 07:36:40 | Re: Are we missing (void) when return value of fsm_set_and_search is ignored? |
| Previous Message | Peter Eisentraut | 2021-06-05 07:29:14 | Re: DELETE CASCADE |