Re: DELETE CASCADE

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.