Re: Practical error logging for very large COPY
От | Tom Lane |
---|---|
Тема | Re: Practical error logging for very large COPY |
Дата | |
Msg-id | 12499.1132679760@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Practical error logging for very large COPY (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: Practical error logging for very large COPY
Re: Practical error logging for very large COPY |
Список | pgsql-hackers |
Greg Stark <gsstark@mit.edu> writes: > I think that's precisely the point here though. There are basically two > categories of errors: > 1) Data that can be parsed and loaded but generates some sort of constraint > violation such as a UNIQUE violation, foreign key violation, or other > constraint violation. > 2) Data that can't be parsed as the correct data type at all. > It would be nice to be able to have the former loaded into an actual table > where it can be queried and perhaps fixed and reloaded. > The latter clearly cannot. Sure it can --- you just have to dump it as raw text (or perhaps bytea, as someone suggested upthread). I think the distinction you are proposing between constraint errors and datatype errors is entirely artificial. Who's to say what is a constraint error and what is a datatype error, especially when you start thinking about cases like varchar length constraints or domain-type constraints? If we create a mechanism that behaves differently depending on whether the error is detected before or after we try to form a tuple containing the data, we're going to have something that is exceedingly awkward to use, because the behavior will be nearly arbitrary from the user's viewpoint. regards, tom lane
В списке pgsql-hackers по дате отправления: