From: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Practical error logging for very large COPY |
Date: | 2005-11-23 04:19:02 |
Message-ID: | 4383EDB6.8050405@familyhealth.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-11-23 04:24:29 | Re: A few pgindent oddities |
Previous Message | Tom Lane | 2005-11-23 04:16:16 | Re: tablespaces and non-empty directories |