Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id E17EB1BFF91C for ; Fri, 6 Apr 2012 12:39:55 -0300 (ADT) Received: from mail-qc0-f174.google.com ([209.85.216.174]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1SGBGU-0004Lr-GM for pgsql-hackers@postgresql.org; Fri, 06 Apr 2012 15:39:55 +0000 Received: by qcro28 with SMTP id o28so1493642qcr.19 for ; Fri, 06 Apr 2012 08:39:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-gm-message-state; bh=aoL3uPatoy2n8/lTdjaPRlbMgH143UUqq6XtYFfR0eA=; b=N1vMU43YSswAidhQR2K7plSkfhWqnf3KacTZLRvm3didZTOgJObsJd/HRHQMB/jzpN rzF5C1QBBIUADXDIYejX/XCO9ivszcgk/NfCLKROlcLqFeJzPMJ7XPdd8p9am9cbY/e/ BPa8SKU6HHkjiZpXXm3uCGw391M/FmxI3gPeJwZVSVY6o726coJHgJBq5mMZ21mJ/szk tiGr125QElvjxiqsO0jKq0pgZoce8DQ3R+QU9Tqj4A+VLS1/kM7DhUtUjUStfPC7XKBf gFvQi1GwMNDXA4Zdidd7ux6nbT8COWxTHHmlOhtl1nWdqKlHBigxggkW8sndHy3/BGkr 0c6A== Received: by 10.224.189.16 with SMTP id dc16mr9119013qab.40.1333726781700; Fri, 06 Apr 2012 08:39:41 -0700 (PDT) Received: from tornado.leadboat.com (ip68-105-236-221.hr.hr.cox.net. [68.105.236.221]) by mx.google.com with ESMTPS id cs10sm11379563qab.8.2012.04.06.08.39.40 (version=SSLv3 cipher=OTHER); Fri, 06 Apr 2012 08:39:41 -0700 (PDT) Date: Fri, 6 Apr 2012 11:39:38 -0400 From: Noah Misch To: Peter Eisentraut Cc: Gianni Ciolli , Tom Lane , Marco Nenciarini , pgsql-hackers@postgresql.org Subject: Re: [PATCH] Support for foreign keys with arrays Message-ID: <20120406153938.GA22529@tornado.leadboat.com> References: <20120121204223.GA2388@tornado.leadboat.com> <4F280EFE.1080604@2ndQuadrant.it> <1328551482.3354.64.camel@greygoo.devise-it.lan> <20120225020135.GA27204@tornado.leadboat.com> <1331748188.6744.15.camel@greygoo.devise-it.lan> <20120317033312.GB19556@tornado.leadboat.com> <1332178899.2278.4.camel@greygoo.devise-it.lan> <12609.1332442965@sss.pgh.pa.us> <20120324100131.GA13561@leggeri.gi.lan> <1333693277.32606.9.camel@vanquo.pezone.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1333693277.32606.9.camel@vanquo.pezone.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-Gm-Message-State: ALoCoQkthNDV7xrh8CPlan65RniCNZRAixaCyuCLkvreDqpYf/7vluOvOSzphZjdc98wHZP+32Th X-Pg-Spam-Score: -2.6 (--) X-Archive-Number: 201204/313 X-Sequence-Number: 206116 On Fri, Apr 06, 2012 at 09:21:17AM +0300, Peter Eisentraut wrote: > On l??r, 2012-03-24 at 10:01 +0000, Gianni Ciolli wrote: > > ON (DELETE | UPDATE) actions for EACH foreign keys > > ================================================== > > > > ------------------ ----------- ----------- > > | ON | ON | > > Action | DELETE | UPDATE | > > ------------------ ----------- ----------- > > CASCADE | Row | Forbidden | > > SET NULL | Row | Row | > > SET DEFAULT | Row | Row | > > EACH CASCADE | Element | Element | > > EACH SET NULL | Element | Element | > > EACH SET DEFAULT | Forbidden | Forbidden | > > NO ACTION | - | - | > > RESTRICT | - | - | > > ------------------ --------- ------------- > > > I took another fresh look at this feature after not having looked for a > month or two. I think the functionality is probably OK, but I find the > interfaces somewhat poorly named. Consider, "PostgreSQL adds EACH > foreign keys" -- huh? I think they key word ELEMENT would be more > descriptive and precise, and it also leaves the door open to other kind > of non-atomic foreign key relationships outside of arrays. EACH has no > relationship with arrays. It might as well refer to each row. Good points. Your proposed naming works for me. > On the matter of the above chart, there has been a long back and forth > about whether the row or the element case should be the default. Both > cases are probably useful, but unfortunately you have now settled on > making maximum destruction the default. Additionally, we would now have > the case that sometimes, depending on some configuration elsewhere, an > ON DELETE CASCADE deletes more than what was actually involved in the > foreign key. What I'd suggest is to make both cases explicit. That is, > forbid ON DELETE CASCADE altogether and make people write ON DELETE > CASCADE ROW or ON DELETE CASCADE ELEMENT. In addition to making things > more explicit and safer, it would again leave the door open to other > kinds of relationships later. I'm ambivalent on this one. ON DELETE CASCADE truly does the same thing regardless of whether the FK incorporates an EACH column. The current syntax arises from that symmetry rather than a decision to dub its behavior as a default. That said, when a user wants CASCADE ELEMENT, your proposal would more-rapidly divert him from wrongly using CASCADE ROW. Thanks, nm