Helen,

> >I would consider this a bug.
> >What is the sense of having CHECK-constraints when I can create
> >data, which fails that check?
>
> With Roman's example, it doesn't fail the check that's defined. The
> incoming value isn't written anywhere yet, so how could it possibly
> participate in the Max() aggregation? At the point the check is
> done, the check constraint is entirely met.

Strictly speaking, after adding a constraint database is not
consistent (there are rows that do not satisfy constraint). And since
database is not consistent, commit should fail (transaction is an
atomic piece of work that brings database from one consistent state to
another, that's "C" in ACID). And even more, after adding this
constraint any subsequent insert will fail. Baackup/restore will fail
as well.

Actually this construct was "invented" to emulate exception on commit
(I wanted to test JayBird's behavior in this case), but I was
surprised when no exception happened.

So, from my point of view:

a) this is a bug, probably similar to the bug with adding NOT NULL
constraint to the columns with NULL values;

b) as it was discussed many time already, it must be fixed.

Roman