Tom,
> AFAIR, whether a constraint is syntactically attached to a column or is
> "loose" in the table definition is not supposed to have any semantic
> consequences, but I might be wrong about that too.
Well, a table-level CHECK constraint can attach to more than one column, so in
that way *is* different, regardless of whatever else the spec says about it.
For example,
table a (
col1 INT,
col2 INT,
CONSTRAINT less_than CHECK (col1 < col2)
);
The fact that the constraint is implemented as a function shouldn't make a
difference for us as long as all of the columns are named:
table users (
username text,
active boolean,
CONSTRAINT username_is_unique CHECK cf_user_unique(username, active)
);
in this case, the constraint should be triggered whenever either of the named
columns is updated. BTW, the above is basically Bricolage's problem ... they
want only active user names to be unique.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
