On Sun, Jan 22, 2012 at 09:06:49PM +0000, Simon Riggs wrote: > On Sat, Jan 21, 2012 at 8:42 PM, Noah Misch <n...@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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
