> As I was reading through the email chain I had this thought: could you
> get the same benefit (or 90% of it anyway) by instead allowing the
> creation of a uniqueness constraint that contains more columns than
> the index backing it? So long as the index backing it still guaranteed
> the uniqueness on a subset of columns that would seem to be safe.
> After writing down that idea I noticed Wolfgang Walther had commented
> similarly, but it appears that that idea got lost (or at least not
> responded to).
Is it necessary to have the unique constraint at all? This currently works
in
PostgreSQL:
CREATE TABLE foo (a integer, b integer);
CREATE UNIQUE INDEX ON foo (a, b);
CREATE TABLE bar (
x integer,
y integer,
FOREIGN KEY (x, y) REFERENCES foo(a, b)
);
Where no unique constraint exists on foo (a, b). Forcing the creation of a
unique constraint in this case seems more confusing to me, as a user, than
allowing it without the definition of the unique constraint, given the
existing
behavior.
> I'd be happy to sign up to review an updated patch if you're
> interested in continuing this effort. If so, could you register the
> patch in the CF app (if not there already)?
The patch should already be registered! Though it's still in a state that
needs
a lot of work.
