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. For me, one array column, no other non-array columns and delete restrict would cover 90+% of use cases. Bearing in mind you can cover other cases by writing your own triggers, I don't think solving every problem makes sense in a single release. Once we have a solid base we can fill in the rare cases later. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
