Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
От | Tom Lane |
---|---|
Тема | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |
Дата | |
Msg-id | 2592557.1675663234@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)
|
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On February 5, 2023 9:12:17 PM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Damir Belyalov <dam.bel07@gmail.com> writes: >>> InputFunctionCallSafe() is good for detecting errors from input-functions >>> but there are such errors from NextCopyFrom () that can not be detected >>> with InputFunctionCallSafe(), e.g. "wrong number of columns in row''. >> If you want to deal with those, then there's more work to be done to make >> those bits non-error-throwing. But there's a very finite amount of code >> involved and no obvious reason why it couldn't be done. > I'm not even sure it makes sense to avoid that kind of error. And > invalid column count or such is something quite different than failing > some data type input routine, or falling a constraint. I think it could be reasonable to put COPY's overall-line-format requirements on the same level as datatype input format violations. I agree that trying to trap every kind of error is a bad idea, for largely the same reason that the soft-input-errors patches only trap certain kinds of errors: it's too hard to tell whether an error is an "internal" error that it's scary to continue past. regards, tom lane
В списке pgsql-hackers по дате отправления: