| From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
|---|---|
| To: | Neil Conway <neilc(at)samurai(dot)com> |
| Cc: | Hannu Krosing <hannu(at)skype(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Subject: | Re: VLDB Features |
| Date: | 2007-12-14 19:39:49 |
| Message-ID: | 4762DC05.1070003@dunslane.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Neil Conway wrote:
> On Fri, 2007-12-14 at 14:48 +0200, Hannu Krosing wrote:
>
>> How did you do it ?
>>
>> Did you enchance COPY command or was it something completely new ?
>>
>
> By modifying COPY: COPY IGNORE ERRORS or some such would instruct COPY
> to drop (and log) rows that contain malformed data. That is, rows with
> too many or too few columns, rows that result in constraint violations,
> and rows containing columns where the data type's input function raises
> an error. The last case is the only thing that would be a bit tricky to
> implement, I think: you could use PG_TRY() around the InputFunctionCall,
> but I guess you'd need a subtransaction to ensure that you reset your
> state correctly after catching an error.
>
>
>
Ideally I think you would put the failing input line in another table,
or maybe another file. If a table, it would probably have to be as bytea.
cheers
andrew
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-12-14 23:22:41 | Re: VLDB Features |
| Previous Message | Neil Conway | 2007-12-14 19:27:03 | Re: VLDB Features |