Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n7ZRu-00011G-3V for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Jan 2022 08:57:42 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1n7ZRs-0006uB-0J for pgsql-hackers@arkaria.postgresql.org; Wed, 12 Jan 2022 08:57:40 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n7ZRr-0006tq-Le for pgsql-hackers@lists.postgresql.org; Wed, 12 Jan 2022 08:57:39 +0000 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1n7ZRn-0005ua-WC for pgsql-hackers@postgresql.org; Wed, 12 Jan 2022 08:57:39 +0000 Received: by mail-pl1-x62a.google.com with SMTP id n11so1209507plf.4 for ; Wed, 12 Jan 2022 00:57:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=aXyeTcbr9wd/Ap+Na04aNBMcTpkRloLVyfSW3qo3s24=; b=G86jtnO3yT4keeypztbuNYWsrCtdOYFq6x7VQ5BZFtRF0p+nhQfeY97NQW5ZNwzMUY JV75bLKJUHw6/IL7h4Abqqk4J9YowpX7W3SJybnDCofTEHUU9YqKaQYHUvPj+qz8AhlT vUF0HFkTIdN3T8d08I9u8XxWvJzT8nyaJcEoc29OtYXgKlEXnNQrGd02xSRyk/lzjODK vJxIeu/M1ujicyD4c9sqSQedSQEOxKN8S9UVbgvx39TQdIpbgtVfRzJ/YLDtIFeTUQRQ Pl9I8sMnEC8QFYFBXINOnEDBQWZUoqBsq4uKAURb6PjddVWelfRonuBYbViF9gij0SPZ ++hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=aXyeTcbr9wd/Ap+Na04aNBMcTpkRloLVyfSW3qo3s24=; b=1mCI/SmVy3TMtnCAiX9dlOsCCs7phbsX5RPHfBIRplYvGYxdn6Fp+8iYMw8ibnTRtn Rp/S+BTb34V2+Px0OjQOGnJ/iUS7C8tg2T/2ExWlH2m1CIXWOeB6H597AbXWt4NYchJv XYvQYSzwoM887SNdvRdzHm9kj36iKnuBfZeC8CgbAQd2zeAvaJ5SHZ1geqkkhrZMb8hv D9IojiWbl+rchDK0QUg76o+YBBOrxEgN1empzS//1h9K8mo7nYPuutR0V9YO3+x1kb6y zcj4Gy+tNtRV2yekOjJ7YPvQ8ristUW7zx0qqRGv4vtR2ApspeXKsCY0kRG8rEydeQGF xhNg== X-Gm-Message-State: AOAM5324DfLLRDwj3ZpAJ1RyRagNzCxDmIxnxYh+Xqr1AuB903NqEANR Bh/Xk9x0453jqq7D7fMHYz8= X-Google-Smtp-Source: ABdhPJxEI7TaPk3WqS53VzLg9bzqR3J+iSZZy4vK+TfWLVvmJL7t57vrlaHGhehRU/GzGOg3AWeegA== X-Received: by 2002:a17:902:db12:b0:149:4b97:5a20 with SMTP id m18-20020a170902db1200b001494b975a20mr8257371plx.103.1641977853784; Wed, 12 Jan 2022 00:57:33 -0800 (PST) Received: from jrouhaud (1-171-174-202.dynamic-ip.hinet.net. [1.171.174.202]) by smtp.gmail.com with ESMTPSA id x23sm4739392pjd.40.2022.01.12.00.57.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Jan 2022 00:57:31 -0800 (PST) Date: Wed, 12 Jan 2022 16:57:27 +0800 From: Julien Rouhaud To: David Christensen Cc: Tom Lane , "David G. Johnston" , Peter Eisentraut , PostgreSQL-development Subject: Re: DELETE CASCADE Message-ID: <20220112085727.rxzbe3u2ebidht5a@jrouhaud> References: <2432009.1632502808@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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.