Geoff,

> > If you want the firebird users base to grow, you need to
> > adhere standards.
>
> > So, there must be a hard reason to violate it or it is a bug.
>
> No... There must be a hard reason to violate it or it is not
> standards compliant.
>
> There is a significant difference between a "bug" and standard
> compliance (and what level of compliance etc).
>
> As for a "hard reason", how about: Its the only way that makes
> sense. :-)
>
> I dont know why the current implementation was done this way,
> but being the logical way to do integrity checking seems to
> be a likely explanation.
>
> To test integrity after you have made a change (ie. lets do it
> and see what breaks) seems like an unreasonable way to perform
> integrity checks - something you resort to only as a last
> resort.
>
> As to why the standard should say to do it after the change.
> I do not know. I cannot see any useful reason to do it this
> way, I can only assume that a committee has been involved. ;-)

I'm surprise you're saying this...

As I have written before, a check constraint can be of different
"levels".

An easy-to-check check constraint could be:
mycol < 20

Obviously, this could easily be done in a (system) BEFORE
<action> trigger.

Unlike check constraints that depend on other tables for
some kind of integrity check. These are valid constraints
and valid concerns...

A database system should be able to check and keep your
data valid by using unique/pk constraints, fk constraints and
custom written (procedural) check constraints. This is why
we have deferred and immediate constraints.

As, I believe, Ann already wrote:

create un_table (c1 int unique)
<insert rows>
update un_table set c1 = c1 + 1

is valid.

Try it in Firebird :-)

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com