Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125])
	by mail.postgresql.org (Postfix) with ESMTP id CE5191921271
	for <pgsql-hackers@postgresql.org>;
	Sun, 22 Jan 2012 22:31:03 -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 1Rp9gT-0001sO-Jx
	for pgsql-hackers@postgresql.org; Mon, 23 Jan 2012 02:31:02 +0000
Received: by qcsf13 with SMTP id f13so1314115qcs.19
	for <pgsql-hackers@postgresql.org>;
	Sun, 22 Jan 2012 18:30:49 -0800 (PST)
Received: by 10.229.78.89 with SMTP id j25mr2025068qck.46.1327285849187;
	Sun, 22 Jan 2012 18:30:49 -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 dk2sm23829245qab.12.2012.01.22.18.30.46
	(version=SSLv3 cipher=OTHER); Sun, 22 Jan 2012 18:30:47 -0800 (PST)
Date: Sun, 22 Jan 2012 21:30:45 -0500
From: Noah Misch <noah@leadboat.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Marco Nenciarini <marco.nenciarini@2ndquadrant.it>,
	Gabriele Bartolini <gabriele.bartolini@2ndquadrant.it>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Support for foreign keys with arrays
Message-ID: <20120123023045.GD15693@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>
	<20111212004506.GB10399@tornado.leadboat.com>
	<1326568728.2613.16.camel@greygoo.devise-it.lan>
	<20120121204223.GA2388@tornado.leadboat.com>
	<CA+U5nML-xQYigwy3zPybs=+CNeOtwo-1LZ15D28oF19Hccr1Cg@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: 
 <CA+U5nML-xQYigwy3zPybs=+CNeOtwo-1LZ15D28oF19Hccr1Cg@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
X-Gm-Message-State: 
 ALoCoQlIUxhc/S2LfjnKM1UikE5a2PhBAqyzPN0QiGgfIr9ddG+MAXKU/8MWh0R34VuvpuBT55pl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Pg-Spam-Score: -2.6 (--)
X-Archive-Number: 201201/1257
X-Sequence-Number: 201845

On Sun, Jan 22, 2012 at 09:06:49PM +0000, Simon Riggs wrote:
> On Sat, Jan 21, 2012 at 8:42 PM, Noah Misch <noah@leadboat.com> wrote:
> 
> > You currently forbid multi-column EACH FKs. ?I agree that we should allow only
> > one array column per FK; with more, the set of required PK rows would be
> > something like the Cartesian product of the elements of array columns.
> > However, there are no definitional problems, at least for NO ACTION, around a
> > FK constraint having one array column and N scalar columns. ?Whether or not
> > you implement that now, let's choose a table_constraint syntax leaving that
> > opportunity open. ?How about:
> > ? ? ? ?FOREIGN KEY(col_a, EACH col_b, col_c) REFERENCES pktable (a, b, c)
> 
> 
> I don't think we should be trying to cover every possible combination
> of arrays, non-arrays and all the various options. The number of
> combinations is making this patch larger than it needs to be and as a
> result endangers its being committed in this release just on committer
> time to cope with the complexity. We have a matter of weeks to get
> this rock solid.
> 
> Yes, lets keep syntax open for future additions, but lets please
> focus/edit this down to a solid, useful patch for 9.2.

+1.  Let's change the syntax to leave that door open but not use the
flexibility at this time.