>>> Issue I'm thinking about is that when we commit transaction
>>> database becomes unrestorable (i.e. one has to restore it without
>>> constraints first, then repair the DB, then backup it and restore it
>>> again)...
>>
>> Yes, this is specific of our backup\restore process. Note, i don't offer to not check
>> constraints. I just said it may improve performance if would be done at the second phase
>> of bulk load process (which i believe is one statement). I.e. after data load but before
>> the return from statement. Therefore possible temporary constraint violation is invisible
>> for user.
>
> Are we talking about deferred constraint evaluation by a chance? :)

More or less - yes ;) But this is not "true" deferred constraint - in my case its
deferred until end of statement, not end of transaction. It may be easyer to
implement i think

>> And of course user triggers can be bypassed without any harm for physical
>> database consistency.
>
> Hmmmm...

I mean it can't made database un-restorable for gbak

Regards,
Vlad