Re: restore whoes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Simone Tellini <tellini(at)areabusiness(dot)it>, pgsql-admin(at)postgresql(dot)org
Subject: Re: restore whoes
Date: 2002-02-11 21:34:00
Message-ID: 15618.1013463240@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Chad R. Larson 2002-02-11 22:20:27 Re: restore whoes
Previous Message Peter Eisentraut 2002-02-11 21:29:30 Re: restore whoes