Gotcha. This is indeed to ensure a specialized ref integrity bit,
against a column which "ought not ever change". Once some more old
code goes away, then can fully normalize this area, making this check
subselect bit go away, replaced by a regular FK.
Hmm -- probably could even now make it a FK against a column which is
not the pri key of the foreign table, and it'd work better and would
ensure consistence against changes on the foreign table side, eh?
Thanks!
On Nov 29, 2006, at 12:53 PM, Stephan Szabo wrote:
To completely get the constraint, you have to also apply
constraints on
the tables referenced in the function that prevent modifications on
those
tables from causing the constraint to be violated. For example, if you
were to do an exists test on another table for a row that matches
up with
this row in some fashion (for a specialized referential integrity
constraint) modifications on that other table could also cause the
constraint to be violated, but that isn't caught by the CHECK
function(...) case and you'll probably need triggers or other
constraints
on that table.
----
James Robinson
Socialserve.com
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
