Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id 9B48B7E7FA9
	for <pgsql-hackers@postgresql.org>;
	Sun, 11 Dec 2011 20:45:24 -0400 (AST)
Received: from mail-qy0-f174.google.com ([209.85.216.174])
	by makus.postgresql.org with esmtp (Exim 4.72)
	(envelope-from <noah@leadboat.com>) id 1RZu1C-0007Ib-Lo
	for pgsql-hackers@postgresql.org; Mon, 12 Dec 2011 00:45:24 +0000
Received: by qcqz2 with SMTP id z2so3226407qcq.19
	for <pgsql-hackers@postgresql.org>;
	Sun, 11 Dec 2011 16:45:10 -0800 (PST)
Received: by 10.229.67.203 with SMTP id s11mr3956627qci.58.1323650709918;
	Sun, 11 Dec 2011 16:45:09 -0800 (PST)
Received: from tornado.leadboat.com (ip68-230-222-48.rd.hr.cox.net.
	[68.230.222.48])
	by mx.google.com with ESMTPS id z1sm33350591qao.1.2011.12.11.16.45.08
	(version=SSLv3 cipher=OTHER); Sun, 11 Dec 2011 16:45:09 -0800 (PST)
Date: Sun, 11 Dec 2011 19:45:06 -0500
From: Noah Misch <noah@leadboat.com>
To: Gabriele Bartolini <gabriele.bartolini@2ndQuadrant.it>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Marco Nenciarini <marco.nenciarini@2ndquadrant.it>
Subject: Re: [PATCH] Support for foreign keys with arrays
Message-ID: <20111212004506.GB10399@tornado.leadboat.com>
References: <4EB3DF02.4020604@2ndQuadrant.it>
	<20111117042841.GA20517@tornado.leadboat.com>
	<4EC8CA0F.8040405@2ndQuadrant.it>
	<20111120130526.GD12013@tornado.leadboat.com>
	<4EE31CB9.90005@2ndQuadrant.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EE31CB9.90005@2ndQuadrant.it>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Pg-Spam-Score: -2.6 (--)
X-Archive-Number: 201112/427
X-Sequence-Number: 199679

On Sat, Dec 10, 2011 at 09:47:53AM +0100, Gabriele Bartolini wrote:
> Il 20/11/11 14:05, Noah Misch ha scritto:
>> What about making ON UPDATE CASCADE an error?  That way, we can say that ARRAY
>> <action>  always applies to array elements, and plain<action>  always applies to
>> entire rows.
>>
>> SET DEFAULT should now be fine to allow.  It's ARRAY SET DEFAULT, in your new
>> terminology, that wouldn't make sense.
>
> I have tried to gather your ideas with Gianni's and come to a  
> compromise, which I hope you can both agree on.
>
> The reason why I would be inclined to leave CASCADE act on rows (rather  
> than array elements as Gianni suggests) is for backward compatibility  
> (people that are already using referential integrity based on array  
> values). For the same reason, I am not sure whether we should raise an  
> error on update, but will leave this for later.

Your conclusion is reasonable, but I don't understand this argument for it.  The
patch does not change the meaning of any SQL that works today.

> So, here is a summary:
>
> --------------- --------- ---------
>                |   ON    |   ON    |
> Action         | DELETE  | UPDATE  |
> --------------- --------- ---------
> CASCADE        |   Row   |  Error  |
> SET NULL       |   Row   |   Row   |
> SET DEFAULT    |   Row   |   Row   |
> ARRAY CASCADE  | Element | Element |
> ARRAY SET NULL | Element | Element |
> NO ACTION      |    -    |    -    |
> RESTRICT       |    -    |    -    |
> --------------- --------- ---------
>
> If that's fine with you guys, Marco and I will refactor the development  
> based on these assumptions.

Looks fine.