>> 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? :)

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

Hmmmm...

>>>>> Permissions
>>>>> Only members of the sysadmin and bulkadmin fixed server roles can execute BULK INSERT.
>>>> Hmmm... personally I would go with GRANT BULK INSERT ON <...> TO <...> .
>>> This is the same as including user into bulkadmin server role (in MSSQL of course)
>> Conceptually yes, but gives a flexibilty to give bulk insert on table a
>> to user john and on table b to user mary.
>
> You right here. If we need such level of flexibility ;)

I just don't like built-in roles with built-in permissions. :)

Roman