Peter Eisentraut <peter_e@gmx.net> writes:
> ISTM that this class of problem should be avoided by reading COPY input as
> a text stream rather than a binary stream on all operating systems.
> Doesn't that effectively guarantee that your program sees the end of the
> line as "\n" only, no matter how it's actually stored?
(1) No, that just guarantees that we have no control over the breakage
or recovering from it. Our real problem is that COPY's data
representation is not newline-translation-proof; opening up an
additional place where newline translation might or might not occur
cannot fix this problem, it can only make it worse.
(2) On Unix machines, "text mode" I/O does not do anything different
from binary mode anyway. Our problem is with pg_dump data that has
temporarily left the Unix world and been munged in transit. We want
to be able to deal with that whether or not the local libc has ever
heard of \r\n newlines.
regards, tom lane
