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