Technically you are not allowed to make an FK to non-unique
values. What you're closer to looking for is MATCH PARTIAL
which we don't support (because it's a real pain - although
with the new memory management stuff in 7.1 it may be less
of one - since the fundamental problem is storing values
from other iterations of the trigger for this last update/delete
for ref actions).
7.1 won't let you define such a constraint with the create
table or alter table syntaxes (I guess theoretically it would
let you create constraint trigger and bring the broken
constraint from an older version). Right now we don't
support constraining views because we don't have a mechanism
in place to rewrite the constraint to actually work.
On Tue, 6 Feb 2001, Josh Berkus wrote:
> Tom et al.
>
> Discovered this quirk in foriegn keys:
>
> In the preliminary version of a database, I added foriegn
> key constraints to a number of tables, linking them to a
> column in a shared reference table (status.status) that was
> only one-half of a composite primary key (and thus the
> values were not unique). When I tried to delete a row
> containing a "2" in the status column from the status
> relation, I received a Foreign Key violation error event
> though there were other "2"'s in the table still present.
>
> So ... is this a bug in forign key implementation, or just
> my fault for keying off a non-unique value?
>
> And, if the latter, is there a way I can construct a foreign
> key constraint that keys onto a view or query?
