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?
The referenced columns of a foreign key constraint shall have
a unique constraint. That's how it is in the SQL specs. So
it is a bug that the system let's you specify the constraint
at all. I think Stephan fixed it for 7.1.
OTOH Postgres doesn't (and shouldn't) enforce it after,
because if it would, you couldn't drop/create a corrupted
index.
And no, you can't actually reference to a view or anything
else than a table. That is, because the system wouldn't know
how to check for the DELETE/UPDATE cases on the base tables
building the view if the removal of a key would violate
existing references.
For such custom setups, we have procedural languages and
triggers.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== [EMAIL PROTECTED] #
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
