From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Marco Nenciarini <marco(dot)nenciarini(at)2ndquadrant(dot)it>, Gabriele Bartolini <gabriele(dot)bartolini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Support for foreign keys with arrays |
Date: | 2012-01-23 02:30:45 |
Message-ID: | 20120123023045.GD15693@tornado.leadboat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)leadboat(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2012-01-23 03:16:57 | Re: Optimize binary serialization format of arrays with fixed size elements |
Previous Message | Robert Haas | 2012-01-23 02:20:44 | Re: PG-Strom - A GPU optimized asynchronous executor module |