> Actually, there are really only a few errors people want to trap I
> imagine:
>
> - CHECK constraints (all handled in ExecConstraints)
> - Duplicate keys
> - Foreign key violations (all handled by triggers)
>
> Rather than worry about all the events we can't safely trap, how about
> we simply deal with the handful that are trappable. For example, we let
> people create an ON ERROR trigger and use the existing trigger
> interface. We have three possibilities:
Trap as many as we can and in the 'rejects' table have an 'sqlstate'
field that has the SQLSTATE code generated by the failure. That way you
can trivially look for all the ones that failed for whatever reason you
like.
Chris