Re: DELETE CASCADE - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: DELETE CASCADE
Date
Msg-id 20220112085727.rxzbe3u2ebidht5a@jrouhaud
Whole thread Raw
In response to Re: DELETE CASCADE  (David Christensen <david.christensen@crunchydata.com>)
Responses Re: DELETE CASCADE
List pgsql-hackers
Hi,

On Wed, Sep 29, 2021 at 03:55:22PM -0500, David Christensen wrote:
> 
> I can see the argument for this in terms of being cautious/explicit about what gets removed, however
> the utility in this particular form was related to being able to *avoid* having to manually figure out
> the relationship chains and the specific constraints involved.  Might there be some sort of middle
> ground here?
> [...]
> > I think we could do something like extending the syntax to be
> >
> >     SET CONSTRAINTS conname [ON tablename] [,...] new_properties
> 
> This part seems reasonable.  I need to look at how the existing SET CONSTRAINTS is implemented;
> would be interesting to see how the settings per-table/session are managed, as that would be
> illustrative to additional transient state like this.

The cfbot reports that this patch doesn't apply anymore:
http://cfbot.cputube.org/patch_36_3195.log

> patching file src/backend/utils/adt/ri_triggers.c
> Hunk #1 succeeded at 93 (offset 3 lines).
> Hunk #2 FAILED at 181.
> Hunk #3 succeeded at 556 (offset 5 lines).
> Hunk #4 succeeded at 581 (offset 5 lines).
> Hunk #5 succeeded at 755 (offset 5 lines).
> Hunk #6 succeeded at 776 (offset 5 lines).
> 1 out of 6 hunks FAILED -- saving rejects to file src/backend/utils/adt/ri_triggers.c.rej

Are you currently working on a possibly different approach and/or grammar?  If
not, could you send a rebased patch?  In the meantime I will switch the cf
entry to Waiting on Author.



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: POC: Cleaning up orphaned files using undo logs
Next
From: Amit Kapila
Date:
Subject: Re: row filtering for logical replication