Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Damir <dam.bel07@gmail.com>, torikoshia <torikoshia@oss.nttdata.com>, Pgsql Hackers <pgsql-hackers@postgresql.org>, daniel@yesql.se, anisimow.d@gmail.com, HukuToc@gmail.com, Andrey Lepikhov <a.lepikhov@postgrespro.ru>, Alena Rybakina <lena.ribackina@yandex.ru>
Date: 2023-11-08T23:53:58Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
doc: Fix COPY ON_ERROR option syntax synopsis.
- f6f8ac8e75c9 17.0 landed
-
Disallow specifying ON_ERROR option without value.
- a6d0fa5ef840 17.0 landed
-
Rename COPY option from SAVE_ERROR_TO to ON_ERROR
- b725b7eec431 17.0 landed
-
Fix spelling in notice
- 58fbbc9d683c 17.0 landed
-
Add new COPY option SAVE_ERROR_TO
- 9e2d8701194f 17.0 landed
Hi, On 2023-11-08 13:18:39 -0500, Tom Lane wrote: > Damir <dam.bel07@gmail.com> writes: > > [ v7-0002-Add-new-COPY-option-IGNORE_DATATYPE_ERRORS.patch ] > > Sorry for being so late to the party, but ... I don't think this > is a well-designed feature as it stands. Simply dropping failed rows > seems like an unusable definition for any application that has > pretensions of robustness. Not everything needs to be a robust application though. I've definitely cursed at postgres for lacking this. > I think an actually usable feature of this sort would involve > copying all the failed lines to some alternate output medium, > perhaps a second table with a TEXT column to receive the original > data line. (Or maybe an array of text that could receive the > broken-down field values?) Maybe we could dump the message info, > line number, field name etc into additional columns. If we go in that direction, we should make it possible to *not* use such a table as well, for some uses it'd be pointless. Another way of reporting errors could be for copy to return invalid input back to the client, via the copy protocol. That would allow the client to handle failing rows and also to abort if the number of errors or the type of errors gets to be too big. Greetings, Andres Freund