Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Damir <dam.bel07@gmail.com>
Cc: torikoshia <torikoshia@oss.nttdata.com>,
Pgsql Hackers <pgsql-hackers@postgresql.org>, andres@anarazel.de,
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-08T18:18:39Z
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
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. "But", you say, "we're emitting WARNING messages about it". That's *useless*. For most applications WARNING messages just go into the bit bucket, or worse they cause memory leaks (because the app never reads them). An app that tried to read them would have to cope with all sorts of fun such as translated messages. Furthermore, as best I can tell from the provided test cases, the messages completely lack basic context such as which field or line the problem occurred in. An app trying to use this to understand which input lines had failed would not get far. 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. Also it'd be a good idea to have a vision of how the feature could be extended to cope with lower-level errors, such as lines that have the wrong number of columns or other problems with line-level syntax. I don't say we need to cope with that immediately, but it's going to be something people will want to add, I think. regards, tom lane