>IIRC,SQL92 recommends to handle this case
>as ASSERTIONS rather than as CONSTRAINTS.
Yeah, that was my first thought was to build
them and try to make the constraint look like
an assertion. That doesn't get around locking
though.
>The implementation would be quite different from
>that of (current) column constraints.
>I've been suspicious if it could be implemented
>properly and effectively.
>For example,are there any discussions about
>locking needed to guarantee the consistency ?
Not yet, and I'm not sure the backend even provides
the necessary hooks right now (I haven't looked).
For example, what rows get locked when you are
checking a count(*) constraint (apart from grabbing
a lock on all the tables involved). How do you
prevent someone from inserting a new row that matches
a criteria until your check is finished (locking
non-existant rows). It's much easier in the
alter table case since I already have a table lock
there. :(
I want to do the table/columns that a constraint
references anyway, so that we can move towards
having drops that cascade/restrict.